gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-make experiment


From: Alex Perez
Subject: Re: gnustep-make experiment
Date: Sun, 11 Feb 2007 14:30:15 -0800
User-agent: Thunderbird 2.0pre (Macintosh/20070210)

Richard Frith-Macdonald wrote:

On 11 Feb 2007, at 04:33, Matt Rice wrote:

On 2007-02-10 17:34:59 -0800 Nicola Pero <address@hidden> wrote:

The only objection i've heard from gnustep.pc is "Its not the way GNUstep stores information".
Here is a refresher --
1. it adds an external dependency upon which *everything* would depend

an entirely optional dependency, people could continue sourcing GNUstep.sh.

That implies that either you expect people to write makefiles which are deliberately non-portable (ie they make use of pkg-config and don't work on systems where pkg-config is not installed) or you require them to adopt some convention for having the makefile determine whether pkg-config is available, use it if is, and tell them to source GNUstep.sh if it isn't (presumably include several lines at the top of each makefile). To while it could be optional, it could not be optional in a transparent way. So Nicola's objection stands .... it adds a dependency, or unpleasent consequences of working round the natural dependency.

No, you make GNUstep-make do this for the user. Doesn't this seem obvious?


2. it is slower

-make is not a bottleneck...
for example on my machine....
-make building base here takes 2 minutes 3 seconds...
make when base is already built takes 2 seconds..
where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config

this argument is hogwash.

I agree that performance is not a significant issue ... however, where we are looking at two alternative solutions providing identical benefits in all other respects, this could swing the argument.

They are not identical in *all* other respects, and that's frankly the point.


3. it is designed for something else (which adds complexity)

It does exactly the same thing gnustep-config.sh does.
that adds no complexity...

No difference in complexity of usage, but gnustep-sh parses a simpler file format and uses simpler code so is less complex / more maintainable in that sense. However I suspect the issue is pretty much unimportant.

Exactly, and when it's unimportant, frankly, familiarity for newcompers should be taken into consideration. It's absolutely not being, and in fact, it's been rejected repeatedly by Nicola. I dare say you are not approaching this conversation from a rational point of view, and perhaps have too much emotional investment in make, something you care deeply about. This is an all-too-common problem with OSS developers. Take a few steps back and look at things from everyone elses' perspective, instead of trying to shoehorn your own beliefs into everyone else's perspective. Dependophobia is a treatable condition, and it's usually illogical anyways, most definitely in this case, where it's purely an optional dependency, and where most people are going to have pkgconfig on their system anyways, due to the fact that hundreds of other libs on their system already depend on it. Once again, pkgconfig is a red herring under windows. It's not needed nor is it necessary. Windows has its own mechanisms.


4. it requires rewriting and redesigning stuff with no clear advantages

there are clear advantages...
now I can add stuff to configure for things *using* gnustep-make which attempts to see if
GNUstep libraries exist.

there could be a way to bootstrap gnustep-make to "just work" without any gnustep specific
environment variables.

Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect.

They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]