activation thought

[Michael Meeks]

On Fri, 2003-10-24 at 21:42, Owen Taylor wrote:
> The decision to do pkg-config in C not Perl, shell, Python, etc. was
> very much intentional. (I wrote some non-working code for pkg-config 
> that I gave to Havoc initially. I think he loaded the files,
> deleted everything, and started over. And I do speak Perl.)

	Hmm ;-)

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

	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.

> 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.
or
	* adding a simple perl script - implying no extra dependencies

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

	Just a thought anyway,

	Regards,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot