[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-make experiment

From: Richard Frith-Macdonald
Subject: Re: gnustep-make experiment
Date: 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 committed it.

Minor nit... isn't meant to be executed, not sourced?
 So shouldn't it be named gnustep-config instead of

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

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 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:
macros to be included in 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 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]