Re: gnustep-make experiment

[Richard Frith-Macdonald]

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

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

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

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

> > > The objection i have with GNUstep.conf is it isolates gnustep  
> > > from the rest of the world.
> > I find that objection vague.  Can you explain the practical  
> > meaning of
> > "it isolates gnustep from the rest of the world" ?
> > It's a text file in /etc/GNUstep.conf containing something like
>
> it can be set by --with-config-file when configuring make.
> If this is done, GNUstep can find GNUstep.conf without setting
> GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is
> provided to override the location of /etc/GNUstep.conf if you
> didn't change the default GNUstep.conf location.
> I refuse to rely on a feature which
> a) 99% of the time is fine.
> b) the 1% of the time works unless your relying on GNUstep.conf  
> being findable
>
> theres no way to reliably locate it if the caller was not generated  
> by GNUstep-make's
> configure script.


What that boils down to is the fact that you need to be able to find  
part of GNUstep (eg by having gnustep-config.sh or something else in  
your PATH or having the GNUstep.conf in a standard location).   
Certainly someone can hide GNUstep from you, but why should they.

Of course the same objection applies to pkg-config ... there is no  
way to reliably find that if it is in a non standard location and  
hasn't been put in your PATH.


So to summarise the 'why not to use pkg-config to avoid defining  
GNUSTEP_MAKEFILES':

1. argument stands
2. argument stands but is very weak
3. argument stands but is very weak
4. argument stands, strength depends on the amount of rewriting  
required, which I haven't assessed.

The idea of using pkg-config to avoid defining GNUSTEP_MAKEFILES is  
comprehensively demolished, but the idea was a good one for raising  
the point that it's nice if people can just they 'make' with no other  
preparation needed to build stuff.  I think it makes sense to  
recommend that people use:
GNUSTEP_MAKEFILES ?= $(shell gnustep-config.sh GNUSTEP_MAKEFILES)
include $(GNUSTEP_MAKEFILES)/common.make

All this really has no relevance to whether we want to make pkg- 
config metadata files available for external build systems to use in  
linking with GNUstep libraries, bundles, and frameworks... I think  
that would be a nice feature.  People wanting to produce portable  
packages would not use it, but most developers are probably quite  
happy producing software which only runs on gnu/linux and these  
people could be fairly confident that pkg-config would exist on any  
variant of gnu/linux they want to port to.