[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make experiment
Re: gnustep-make experiment
Mon, 12 Feb 2007 10:19:30 +0000
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
Minor nit... isn't gnustep-config.sh meant to be executed, not
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
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
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
So how does is help with writing configure scripts?
Maybe something like?
if test -z "$GNUSTEP_PATHLIST"; then
And then, once all the variables are set, how should we write
script tests? (and which variables are we allowed to use?)
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
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.
Re: gnustep-make experiment, Nicola Pero, 2007/02/10
Re: gnustep-make experiment, Christopher Armstrong, 2007/02/10
Re: gnustep-make experiment, Nicola Pero, 2007/02/11