|
| From: | Richard Frith-Macdonald |
| Subject: | Re: gnustep-make experiment |
| Date: | 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 innovation.com> wrote: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 dependan entirely optional dependency, people could continue sourcing GNUstep.sh.No, you make GNUstep-make do this for the user. Doesn't this seem obvious?
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 portability/dependency issues. 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 advantagesthere are clear advantages...now I can add stuff to configure for things *using* gnustep-make which attempts to see ifGNUstep libraries exist.there could be a way to bootstrap gnustep-make to "just work" without any gnustep specificenvironment variables.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 do it. 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.
| [Prev in Thread] | Current Thread | [Next in Thread] |