Re: Build system

["A. Pagaltzis" <pagaltzis gmx de>]

* Emmanuele Bassi <ebassi gmail com> [2005-10-13 22:50]:
> 4. I don't remember point four, but it'll come to mind
> eventually.

I can supply one: dependency resolution does not work, because
the Makefile.PL in Gtk2 needs modules from Glib to run at all.

I was talking about this with muppet on IRC today, and he
explained this. The problem as it stands is that these modules
need to do various things at build time which are a pain to do
from within the Makefile. Because of complications of the
interplay beteween the Makefile.PL and Makefile, this means the
Makefile.PL absolutely must complete these tasks *before* it can
set up the build process mechanics it is supposed to.
Unfortunately, these tasks require modules provided by the
distributionâs own dependencies, ie. Gtk2 needs to autogenerate
stuff using Glib::CodeGen. Therefore the Makefile.PL cannot run
without the dependencies already being installed. But automatic
dependency resolution requires Makefile.PL to complete its job.

The bottom line is that as things stand, you have to manually
install the distros in the correct order.

I suggested porting the build system to Module::Build.

The advantage would be that in M::B, the Build.PL which is
equivalent to the Makefile.PL script writes a pureperl Build
script, instead of a Makefile. In contrast to the Makefile, Build
is easily customisable and sanely extensible with new actions,
and without any portability headaches. The upshot is that instead
of doing all the work up front in Build.PL, you can put it where
it belonges: in the Build script. Thus, Build.PL itself does not
require any modules from the dependencies of the distribution in
order to run. And thus, dependency resolution can actually work.

Some issues were raised and discussed regarding Module::Build.

â Concern: the gtk2-perl collective does not depend on anything
  non-core.

  Relief: Gtk2, Glib and friends do have build-time dependencies,
  even if theyâre all stuff from the gtk2-perl team. It doesnât
  really matter whom your non-core build-time dependencies come
  from. And M::B would be a build-time-only dependency, so not
  much effectively changes.

â Concern: M::B has a huge list of dependencies.

  Relief: but almost everything is optional, and the only
  optional dependency that you really *should* install is YAML.

â Concern: mainting two parallel build systems is hateful, but
  rushing right in to switch is not a good idea.

  Relief: thereâs no need to. This should be done as an
  experimental side project at first. Who knows, maybe M::B
  actually sucks for the task at hand. No need to commit to a
  moving to another build systems up front. (Now that would be a
  crazy notion if I ever heard one.)

muppet suggested that I try my hand at it. Unfortunately, I am
a heavily overcommitted procrastinator, so I really canât add
anything more to my plate (and neither can he, he said), so he
asked me to post this to the list in the hopes that maybe someone
else is interested and might pick this up. Or at the very least
it can serve as a reference point to go back to when someone gets
around to this.

In closing, hereâs a exchange overhead in #gtk-perl:

        <muppet> fetching the window system's file descriptor
                 out from under the toolkit is Evil and Wrong.
        <muppet> Fun, but Evil and Wrong.
            <Om> Some people say it's Fun that matters
 [1] <aristotle> -Ofun ?
        <muppet> hehe
        <muppet> -fomit-morals -Ofun
     <aristotle> hahaha
            <Om> hahaha

[1]: http://www.oreillynet.com/pub/wlg/7996

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;