Re: gnustep-make experiment

[Richard Frith-Macdonald]

On 11 Feb 2007, at 11:23, David Ayers wrote:

> Nicola Pero schrieb:
> > I like the idea of your patch, so I rewrote the shell script and  
> > committed it.
>
> Minor nit... isn't gnustep-config.sh meant to be executed, not  
> sourced?
>  So shouldn't it be named gnustep-config instead of gnustep.config.sh?
>
> I'm trying to follow this discussion but it seems that we are not
> addressing the issues which /I/ thought we are trying to solve.

Watching the thread, it became clear to me that it was a confused  
mess of two ideas ...
1. how to obtain information for configure et al (your idea I think)
2. how to have makefiles automatically find the make system (matt  
said this was his primary issue)
So when I butted in, I explicitly/carefully addressed the two  
separately ...

Hopefully issue 1 is done-to-death now, and we can just document use  
of gnustep-config.sh and forget about it.

> I thought the main point was to enable ./configure to test for the
> existence/usability of GNUstep libraries/frameworks.  So shouldn't  
> it be
> installed in into a standard system path instead of
> GNUSTEP_SYSTEM_ROOT/Tools?  I would expect /usr/local/bin or whatever
> --bindir is set to for configure of -make.

Yes, that was/is my understanding of what Nicola was saying about  
gnustep-config.sh

> So how does is help with writing configure scripts?
> Maybe something like?
>
> GNUSTEP_MAKEFILES=${GNUSTEP_MAKEFILES:=`gnustep-config  
> GNUSTEP_MAKEFILES`}
> if test -z "$GNUSTEP_PATHLIST"; then
>    . ${GNUSTEP_MAKEFILES}/GNUstep.sh
> fi
>
> And then, once all the variables are set, how should we write  
> configure
> script tests?  (and which variables are we allowed to use?)
>
> Should we
> 1) tweak the environment to allow AC_CHECK_LIB to work?
> 2) create our own:
> - AC_CHECK_GNUSTEP_LIBRARY
> - AC_CHECK_GNUSTEP_FRAMWORK
> - AC_CHECK_GNUSTEP_NATIVELIBRARY
> macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
> 3) invoke 'make' with gnustep makefiles in some config subdirectory
> during ./configure
> 4) other ideas which I may have missed?
>
> Note that I haven't really understood how pkg-config would be used at
> this level either.  But I get the feeling that we are not solving the
> issues we are aiming at.  But maybe I'm just confused, so I guess it
> would be great if the usage of the two approaches in the context of
> configure scripts could be summarized.

Well, here I feel pkg-config syntax is actually pretty good.  For a  
configure script using pkg-config you would use pkg-config to  
determine/set the CPP/CC/LD flags before calling AC_CHECK_HEADERS and  
AC_CHECK_LIB etc.  I would be happy to just use pkg-config to do the  
same for gnustep packages were it not for the fact that I know it  
wouldn't work on the windows, apple, and sun operating systems I need  
to use sometimes.  It would be great if the gnustep-config.sh script  
could accept the same arguments that pkg-config does, and produce the  
same sort of results for gnustep packages.  That's the kind of  
functionality we need and a usage style familiar to users of pkg- 
config (and convenient for use with the autoconf macros).  Another  
option is to just use pkg-config and bundle it with gnustep-make so  
that the gnustep-make installation process guarantees the presence of  
pgk-config, installing it if necessary.  However, my suspicion is  
that the maintenance overheads involved in making sure we have a pkg- 
config we can use may actually be higher than those involved in  
putting the functionality required into gnustep-config.sh.

Of your list of ideas ... I think
1 is obviously good,
2 i can understand having our own checks for frameworks and bundles,  
but I don't understand the library/nativelibrary distinction ...  
wouldn't you just use AC_CHECK_LIB?
3. OI don't really understand this one.