activation thought

[Owen Taylor]

On Sat, 2003-10-25 at 06:50, Michael Meeks wrote:

[...]

> >  - Efficiency. Running pkg-config for each command in a Makefile
> >    was meant to perform acceptably.
> >  - Portability. Perl may be available almost everywhere. C compilers
> >    are available everywhere.
> >  - Maintainability. Perl can be very maintainable. But the number of
> >    people who can write maintainable Perl is small. 
> 
> 	For a fundamentally text processing task, my feeling is that C is going
> to be harder to develop and maintain, more error prone and hardly more
> performant.

I don't think there has been any real difficulty in pkg-config
development. It's not like we wrote it in shell.

> 	Also - the 1300 lines of the included glib/configure.in looks hardly
> simple / bullet-proof / portable :-) cf. a single 1300 line perl script
> to do the whole task.

The whole point of simply including a version of GLib, is that that
configure script (and GLib) had already been pretty well tested for
workingness and portability. But it certainly has no essential 
connection to the design of pkg-config.

> > Part of the concept of concept of pkg-config is that instead of going
> > through all sorts of hoops so that the user wouldn't have to install
> > a tool, we provide a tool that's very easy to install.
> 
> 	Sure - I guess so; for eg. OO.o I think it comes down to - what is the
> greater risk:
> 
> 	* adding a random auto-tools project requiring sed, [e]grep, tr,
> 	  etc. to even configure - without compiler / linker / porting
> 	  / build issues etc.

If that was really an issue, you could fix it in a day. pkg-config does
not use the deeply system dependent parts of GLib.

> 	* adding a simple perl script - implying no extra dependencies

pkg-config isn't meant for situations where you have some single package
you want to build without reference to anything else on your system.
The goal of pkg-config is to locate installed libraries. If I'm
installing a dozen libraries, installing one small binary doesn't add
a lot of complexity.

> 	Of course, if you don't use perl as part of your build process already,
> I guess there are some circumstances where that doesn't make sense but
> ...

Using Perl as part of the build process is pretty uncommon. E.g., there
is no usage in the entire GTK+ stack. (Neither automake nor gtk-doc get
run by default.)  The GNU standards, in fact, don't allow Perl.

Now from the standards of packages that require *Java* to build, 
requiring Perl probably doesn't seem that bad... :-)

Regards,
							Owen