Re: gstep-make 1.2.0

[Nicola Pero]

(talking about Additional makefiles ... helge is proposing that instead of
loading all the different library-combo additional makefiles each time
(and having each of them protected by a ifeq() for the appropriate combo
having been selected) we put them into subdirs, and gnustep-make will only
load the relevant ones basing on the library combo ... the library-combo
makefiles need not be any longer protected).

> What, if we would source the proper stuff by combo name ?
> 
> Eg:
>   Makefiles
>     runtimes
>       gnu.make
>       co.make
>       nx.make
>     foundations
>       fd.make
>       gnu.make
>       co.make
>       nx.make      
>     guis
>       gnu.make
> 
> The makefiles itself shouldn't have *any* specific flags anymore, but
> only do
> 
> include $(GNUSTEP_MAKEFILES)/foundations/$(FOUNDATION_LIB).make
> 
> This would be really flexible, but I'm not sure whether it would hurt
> performance ?

No problem with performance - it's pretty tempting ... :-) 

We would still include all additional makefiles on the top level dir, but
library-combos makefiles would go into the subdirs ... much cleaner ...
yes quite pretty.

Anyone having any points against this suggestion ?


Helge is also proposing that we add a new library-combo element, `co', for
cocoa ... and use it for cocoa code instead of nx ...  so we would have
the library-combo co-co-co ... I'd like to always use long names and never
acronyms because we want a user friendly system :-) so I'd call it
cocoa-cocoa-cocoa or better apple-apple-apple.

Any comments on this proposal ?