[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
Re: gnustep-make experiment
Mon, 12 Feb 2007 07:18:29 +0000
On 11 Feb 2007, at 22:30, Alex Perez wrote:
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
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.
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
an entirely optional dependency, people could continue sourcing
No, you make GNUstep-make do this for the user. Doesn't this seem
We are discussing how to find gnustep-make ...
If our makefile can use gnustep-make to chose whether or not to use
pkg-config to find gnustep-make, then obviously it has already found
gnustep-make ... in which case there is no reason to use pkg-config
to find gnustep-make.
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 think that's a complete misrepresentation ... I think he just
rejects the religious notion that familiarity is everything. That
attitude leads to turning projects into clones of microsoft products
(or the product used by whatever group you happen to target).
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.
If you look at the aim of the project you will find that it is to be
a cross platform development environment. Among other things, that
means that someone working on one platform should be able to use the
same toolset (as much as reasonably possible) to build their
application on every other platform they want to target. It's fine
and good to be able to use the most popular tools on each platform,
but it's fundamental to the aims of the project to be able to use a
common recommended toolset across all platforms. The nature of the
GNUstep project is that we must be particularly careful about
GNUstep uses the make system because it is highly portable and
effective, and in this case (the ability of a makefile to
automatically locate the make system and get it to run) we have an
example where portability is paramount ... we need to make it as easy
as possible for people to write makefiles which don't need to be
changed when we try to run them on different platforms.
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.
4. it requires rewriting and redesigning stuff with no clear
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
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.
I put it to you that NOBODY knows how pkg-config works to locate the
relevant part of gnustep-make (the topic under discussion) since pkg-
config was not designed to do that, we haven't standardised a way to
The fact that some people know how to use pkg-config in the role it
was designed for does not imply that it's somehow more familiar or
easy to use than a portable alternative in this case.
Re: gnustep-make experiment, Nicola Pero, 2007/02/10
Re: gnustep-make experiment, Christopher Armstrong, 2007/02/10