bug-gnustep
[Top][All Lists]
Advanced

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

Re: Make package fixes (fwd)


From: Nicola Pero
Subject: Re: Make package fixes (fwd)
Date: Fri, 11 Jan 2002 13:41:48 +0000 (GMT)

Thanks - great.

I've applied most of the first patch.  In particular, the point of not
polluting the environment was very good - thanks !

I didn't apply some details - mostly saving in config.make the path to
chown or cygpath ... here is some explanations of why I thought I would
omit those.

about chown, my idea is - 

 the configure test checks that a chown is available on the system.  This
   is meant so that people installing for example on some unix emulation
   environment know they have to install a chown-like tool

 we use the variable CHOWN rather than hardcoding `chown' in commands so
   that if you have more than one chown on your system, you can tell
   gnustep-make to use another one by running 'CHOWN=/opt/nicola/bin/chown
   make'

 but we don't want to hardcode the path to the chown we find during
   configure to the CHOWN variable because we want to make sure that you
   can change the chown you use after you have configured gnustep-make,
   and you don't have to reconfigure.  For example, if you are using
   the system chown when you configure gnustep-make but switch to another
   one later on (say by installing new unix tools in /opt/test/bin, then
   putting that at the beginning of PATH), we want gnustep-make to use the
   new one without having you to reconfigure it.

about cygpath, I'm not the author of that code, but I think the idea is
that you might want to install cygpath.exe, then remove it later on and
have it silently and automatically replaced by gnustep-make's cygpath.sh
... not sure but I suppose if the code to detect cygpath is in GNUstep.sh
and not in configure.in it's because you want it to be able to detect the
available one at runtime.  (maybe instead you're right).

But I much appreciated some tricks in the first patch, thanks :-) and I
applied most of it.


> The second patch (which can be applied after the first one) tries to
> provide additional robustness. It corrects problems with filenames and
> paths that contain whitespace. Several scripts have problems with
> quoting. This patch corrects some, but probably there are more.

I did start to change gnustep-make to support this but ...  it's not
enough to support paths containing whitespaces ... I got into two major
problems

- first is that using an application which is in a directory with a space
in the path, and which has a name which contains a space :-) bash seems to
have a bug in which it can't run the application from a script.

- second is that I played with a configuration in which you configure
gnustep-make by using

./configure --prefix="/opt/GNU step"

that makes sure all gnustep paths have a space in it ... and well that
won't work even after the changes to gnustep-make because the line

include $(GNUSTEP_MAKEFILES)/common.make

in the user makefiles will expand to

include /opt/GNU step/System/Makefiles/common.make

which will not work :-)

If it were in my/system makefiles, I could easily fix it by using

empty:=
space:= $(empty) $(empty)
include $(subst $(space),\ ,$(GNUSTEP_MAKEFILES)/common.make)

but it's in the user makefiles, over which I have no control!

Need to think about this, but probably it's a basic problem in make which
is not really designed to handle paths and filenames containing spaces ...
most make stuff separates filenames by using whitespaces, and I don't know
a way to `quote' a filename in the same way as you do in the shell to
allow a filename to contain a space.  The 'make' authors/designers didn't
probably think you could have paths/filenames containing whitespaces.

I'll probably apply patches to quote most shell paths in next days ...
even if it won't be enough to really support paths/filenames containing
whitespaces in it, it's a start. :-)


> As far as I can tell GNUstep make currently does not support compilation
> in other directories than the source directory. (Using VPATH like
> automake does.) Am I mistaken? It can be useful to have a read-only
> source tree and a separate build directory. Are there any plans to
> support this? (I'm not sure how much work it would be.)

Yes - you are correct - gnustep-make does not support this currently.

It might or might not be difficult to add it, depends on how we want to
add it.  I've already some ideas, but I'd like to check how automake does
it before trying.




reply via email to

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