[Gtk2-perl-bugs] [Bug 341090] Building of Gtk2 Perl module (Makefile.PL) depends on existence of Gtk2 Perl module

[gnome-perl (bugzilla.gnome.org) <bug...@bu...>]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D341090
 gnome-perl | Gtk2 | Ver: unspecified





------- Comment #18 from muppet  2006-05-10 03:41 UTC -------
(In reply to comment #17)
> Look, I am building an automatic builder which builds a lot of thingns.
>
> Search paths as an approach are wrong IMHO - things should rather be
> taken either from the places they are expected to be taken, or not take=
n
> at all.

But there's no real difference between using -I switches on perl's comman=
d line
and using the PERL5LIB environment variable.  In both cases, the end resu=
lt is
the same: directories are prepended to @INC, which is searched for .pm fi=
les.

Whether you like search paths as an approach is beside the point.  Perl u=
ses a
search path to find library modules, and you must take its rules into acc=
ount
in order to use perl.


> I am generating search paths for 'perl Makefile.PL' - I build the depen=
dency
> tree (in this case Gtk2 depends on Glib) and then I look for all direct=
ories
> on which the target depends (in this case directories of Glib) which co=
ntain
> .pm files.
>
> In my case it's the directories you saw. I would prefer not to have
> module-specific build routines, though the script I am developing allow=
s
> this.

But, as I pointed out earlier, filling @INC with every directory that con=
tains
.pm files is wrong.  Consider an object hierarchy that has several adapte=
rs for
an abstract base, such as   My::Thing, My::Foo::Thing, My::Bar::Thing,
My::Baz::Thing.  Each of these actual .pm files is named Thing.pm.  They =
are
disambiguated by the package prefix, which is implemented as parent
directories.  By adding to your path every directory containing .pm files=
,
you'll break this class hierarchy at runtime by always finding the wrong
Thing.pm.  (This is example is munged from one created by a coworker of m=
ine on
a completely unrelated project; it is not theoretical.)

You already know on which modules Foo depends, say Bar.  When you previou=
sly
built Bar, you told it where to install.  You know that it's a perl modul=
e
(because you know you have to run Makefile.PL).  So, you know where its l=
ibrary
files are, because perl's library works in a well-defined (if complicated=
) way.
 All you need to add to Foo's search path is Bar's prefix with slight mun=
ging:

   $ BAR_PREFIX=3D/some/place
   $ FOO_PREFIX=3D/other/place
   $ cd Bar
   $ perl Makefile.PL PREFIX=3D$BAR_PREFIX
   $ make all test install
   $ cd ../Foo
   $ # use a few standard variations of $BAR_PREFIX to be on the safe sid=
e.
   $ # some packages install to perl5, some to perl5/site_perl, and some =
to
perl5/vendor_perl.
   $ perl -I $BAR_PREFIX/lib/perl5 -I $BAR_PREFIX/lib/perl5/site_perl -I
$BAR_PREFIX/lib/perl5/vendor_perl Makefile.PL PREFIX=3D$FOO_PREFIX


> Could you make the two small changes - adding 'use Glib::CodeGen;' in t=
he
> beginning and "require './CodeGen.pm'" instead of "require 'CodeGen.pm'=
" ?

As i said earlier, I have no objection using "./CodeGen.pm" instead of
"CodeGen.pm"; the reason i can't do that right now is that my connection =
to the
CVS tree is somehow hosed.  Torsten, can you make that change?

Adding "use Glib::CodeGen;" to Makefile.PL as you suggest is a non-option=
.=20
That will prevent the script even compiling if you don't have Glib instal=
led,
which is an error condition in which we bend over backwards to give a
meaningful error message to the user.  A more workable solution would be =
to add
it to the eval'd statement that checks for dependencies, but even that is=
,
IMHO, wrong, because it breaks the encapsulation of Gtk2::CodeGen, which
successfully brings in Glib::CodeGen for every build environment that doe=
s not
put invalid directories in the search path.  It is also completely unnece=
ssary
if the explict "./" is added to the require statement.


> Regarding "not a bug".
>=20
> It is possible to build a fully automatic dependency resolution system =
and
> based on it a fully automatic builder for complex projects - provided
> modules do not depend on themselves.
>=20
> In this case Gtk2 module (Perl package) depends on Makefile.PL which
> depends on (locally existing, but still) Gtk2 package/module.

This is a red herring.  The self-dependency is not exposed externally in =
any
way.  The only reason that you're seeing it is a freak namespace clash en=
abled
by an erroneous @INC setting.  And, in any case, depending on yourself is=
 not
at all a bad thing; see below.


> This fact alone kills the possibility to build such an automatic system=
 -
> unless one wants to include into the system all the intricacies of Perl
> packages and build mechanisms.

You already have to include in your system some handling for the fact tha=
t perl
modules use "perl Makefile.PL PREFIX=3D$foo" instead of "./configure
--prefix=3D$foo" and "make test" instead of "make check".  I mentioned ab=
ove a
sufficient and rather simple way to reach the files that a perl build ins=
talls;
such logic would be included in the same module of your build system that
handles building perl modules.  (c.f. the way BuildBot handles autotooled
packages and perl modules and python extensions, etc.)


> There is no real need to build Gtk2 package using pieces from under Gtk=
2
> package.

I disagree in both principle and practice.  Gtk2::CodeGen is used heavily=
 by
Gtk2 to generate large amounts of repetitive definitions that make the bi=
ndings
work.  Gtk2::CodeGen extends Glib::CodeGen with knowledge of GtkObject, w=
hich
the Glib module does not have.  It would be nice if that could be done in=
 the
Makefile itself rather than in Makefile.PL, but because of the way MakeMa=
ker
works, this is not possible.  (The typemaps are needed before the makefil=
e can
be written, and the typemaps are created by Gtk2::CodeGen.)  In fact, our
requirement of all this extra logic in generating the Makefile breaks CPA=
N's
automatic handling of dependencies, which is really a design flaw in CPAN=
.

If your code needs a tool to build, and that tool is not a general purpos=
e
tool, and requires knowledge of the code you're building, then, by all me=
ans,
that tool should be bundled with the code that needs it.

Note that the Glib module uses the same trick with Glib::MakeHelper, whic=
h also
pulls in the documentation generation tools that live in the Glib source =
tree.

Creating the build system for Gtk2-Perl has not been fun.  There are many
aspects of the whole thing that feel like dirty workarounds, but there's =
really
no better solution.  Maintaining twenty or thirty thousand-line Makefile.=
PLs
with heavily duplicated nontrivial code is a far worse evil than the carg=
o-cult
mess we currently have.


> OK, it's not a bug. But, having built a number of build automation syst=
ems,
> I would never have chosen such an implementation...

Trust me, even as ugly as Gtk2-Perl's build system is, it's like the stat=
ue of
David compared to the stuff i've seen in commercial software.


--=20
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.