[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 #17 from Sergei Steshenko  2006-05-10 01:57 UTC -------
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 taken
at all.

I am generating search paths for 'perl Makefile.PL' - I build the depende=
ncy
tree (in this case Gtk2 depends on Glib) and then I look for all director=
ies
on which the target depends (in this case directories of Glib) which cont=
ain
.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 allows
this.

The goal of my script to make the build as automatic as possible.

If you add the 'use Glib::CodeGen;' in the beginning, the two CodeGen mod=
ules
will be disambiguated for good; the suggested "require './CodeGen.pm'"
disambiguates the two CodeGen modules even further and makes sure the one=
 from
current directory is needed.

The main evil of search paths approach is that the result depends on the =
order
of search paths.

I spent countless hours in different places debugging various projects
(pure SW, VLSI projects) just to find out that a wrong version of somethi=
ng
was used - due to the unlucky order of search paths.

So, disambiguating the search is a good thing, and not having it at all i=
s
even better.

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

It shouldn't break things in your builds, but will make life of my script
easier.

...

Regarding "not a bug".

It is possible to build a fully automatic dependency resolution system an=
d
based on it a fully automatic builder for complex projects - provided
modules do not depend on themselves.

In this case Gtk2 module (Perl package) depends on Makefile.PL which
depends on (locally existing, but still) Gtk2 package/module.

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.

There is no real need to build Gtk2 package using pieces from under Gtk2
package.

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


--=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.