Re: Make package fixes (fwd)

[BALATON Zoltan]

On Fri, 11 Jan 2002, Nicola Pero wrote:
> 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).

I don't know Windows and Cygwin/Mingw, but I thought one does not want to
install and remove cygpath.exe. Maybe the original author should clarify
this. Anyway, I think the code that searches for cygpath.exe in the path
should not belong to GNUstep.sh, since looking through the whole path can
take some time and this script is run every time I log in.

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

Hmm, strange. Interestingly ash seems to also have this bug, so it is
probably a feature. It seems that a workaround is to specify such files
with a path component, so either "./app with space" or "`pwd`/app with
space" (with quotes) works, while just "app with space" not.

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

It can be a real problem but I cannot help with this as I'm not a make
expert.

> 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. :-)

In the meantime I've found a bug in executable.template. The part which
tries to find the appname in Info-gnustep.plist fails (before correcting
the quoting it did not even do anything), because if the value of
NSExecutable is not between quotes in the plist file, it leaves the
trailing semicolon in appname. It could be fixed by simply adding a
semicolon to the sed command but the whole thing can be done entirely with
sed. This optimisation should make launching applications faster because
it does without startig three processes: grep, sed, awk and possibly even
echo on some systems. The following patch implements this, but I could
only test it with GNU sed on Linux, so I don't know how portable it is.
(Though theoretically it should work generally.) This could be made more
robust by specifying better regexps (currently it matches NSExecutable
anywhere in a line like the original code).

--- make.sav/executable.template.in     Sun Dec 30 18:58:33 2001
+++ make/executable.template.in Tue Jan 15 20:18:53 2002
@@ -125,10 +125,9 @@
 app=`basename "$app"`
 appname=
 if [ -f "$full_appname/Resources/Info-gnustep.plist" ]; then
-  appname=`grep NSExecutable "$full_appname/Resources/Info-gnustep.plist"`
-  if [ -n "$appname" ]; then
-    appname=`echo "$appname" | sed 's,\", ,g' | awk '{print $3}'`
-  fi
+  appname=`sed -e '/NSExecutable/! d; \
+    /NSExecutable/ s/[ ]*NSExecutable[ ]*=[ ]*\([^ ]*\)/\1/; s/[";]//g; q' \
+    "$full_appname/Resources/Info-gnustep.plist"`
 fi
 if [ -z "$appname" ]; then
   appname=$app

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

I'm not sure about automake, but this is generally done using make's VPATH
feature. The attached patch allows gnustep-make itself to be compiled in
another directory, but I have no idea how could this be done in projects
which use gnustep-make.

gsmake-vpath.patch.gz
Description: gsmake-vpath.patch.gz