Re: Building in a separate directory
BTW, first they moved to JAM, then they internalized JAM's code into Xcode so it's not invoked as a separate process. It's possible that JAM is able to handle spaces, though maybe Apple had to modify it for this. Jam handles spaces (and a number of other things) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On May 27, 2005, at 9:34 AM, David Lázaro Saz wrote: On 27/05/2005, at 13:54, Nicola Pero wrote: The make syntax uses spaces to separate filenames in list of targets or requisites, or everywhere really ... it's a basic design decision in the make syntax. Thanks for the explanation. This also explains why Apple developed a completely new build system for Xcode (xcodebuild). I've tried compiling a Hello World/Hello World.c in my usual (separate) build directory and everything worked. BTW, first they moved to JAM, then they internalized JAM's code into Xcode so it's not invoked as a separate process. It's possible that JAM is able to handle spaces, though maybe Apple had to modify it for this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On 27/05/2005, at 13:54, Nicola Pero wrote: The make syntax uses spaces to separate filenames in list of targets or requisites, or everywhere really ... it's a basic design decision in the make syntax. Thanks for the explanation. This also explains why Apple developed a completely new build system for Xcode (xcodebuild). I've tried compiling a Hello World/Hello World.c in my usual (separate) build directory and everything worked. This being a limitation only for developers seems like an easy to do compromise. Cheers, David. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
> > It might be nice to fix autoconf, but then you'll run into make. > > 'make' doesn't like spaces in directories either - and this is a > > fundamental design issue. > > But doesn't make always run in the same directory? Anyway I'm > placing this on the back burner for some time, and it's been a long > time since I read the GNU make manual. But I think that this issue > needs to be solved someday because directories with spaces are very > common this days (Windows' "C:\Program Files", for example). There is nothing you can do to solve the issue of directories with spaces in it, really. The make syntax uses spaces to separate filenames in list of targets or requisites, or everywhere really ... it's a basic design decision in the make syntax. The problem should be limited to the building process though; meaning if you are building stuff using make, then you need to avoid directories with spaces in it. Once the stuff is built, you should be able to run it anywhere. So end-users should not be affected ... they can run the stuff anywhere. Developers need to avoid compiling inside directories that contain spaces. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
Adam Fedor wrote: On May 26, 2005, at 12:04 PM, David Lázaro Saz wrote: On 26/05/2005, at 1:00, Adam Fedor wrote: It might be nice to fix autoconf, but then you'll run into make. 'make' doesn't like spaces in directories either - and this is a fundamental design issue. But doesn't make always run in the same directory? Anyway I'm placing this on the back burner for some time, and it's been a long time since I read the GNU make manual. But I think that this issue needs to be solved someday because directories with spaces are very common this days (Windows' "C:\Program Files", for example). I'm now deeply immersed in cross-compiling, though. I'm also reviewing how Autoconf works and how it's applied through GNUstep. My knowledge of Autoconf is somewhat superficial right now. The first problem I've detected is that the macro AC_FUNC_SETPGRP prevents cross-compiling because it always needs to run the test program that it constructs in order to check the signature of setpgrp. I haven't found how to circumvent it yet. if test $cross_compiling = no; then AC_FUNC_SETPGRP else #set a default value fi I was working on that, but the default for MingW is not what the normal default would be, but I wasn't entirely sure. Autoconf is rather easy to work around, as long as you have the informations on the correct settings for the traget system. Perhaps it would even be possible to run autoconf on the target system and transfer the results to the actual build environment? For simple settings like AC_FNUC_SETGRP it is sufficent to set an environment variable stating the presense/absense of the feature. Here the settings I used to cross compile for an ARM system: export cl_cv_c_longlong=yes export ac_cv_func_setpgrp_void=yes ./configure --prefix=/home/zaurus/gnustep --disable-flattened \ --host=arm-linux --build=ix86-linux \ --libdir=/home/zaurus/gnustep/System/Library/Libraries/arm/linux-gnu \ --includedir=/home/zaurus/gnustep/System/Library/Headers/gnu-gnu-gnu \ --disable-do > For me this looks easier than trying to guess the correct default value for all the systems and hard coding that in the .ac file. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On 26/05/2005, at 20:52, Adam Fedor wrote: Actually, now I look at the code, it could probably just be: if test $cross_compiling = no; then AC_FUNC_SETPGRP fi I'll try that; I think that would be sufficient too. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On May 26, 2005, at 12:36 PM, Adam Fedor wrote: if test $cross_compiling = no; then AC_FUNC_SETPGRP else #set a default value fi I was working on that, but the default for MingW is not what the normal default would be, but I wasn't entirely sure. Actually, now I look at the code, it could probably just be: if test $cross_compiling = no; then AC_FUNC_SETPGRP fi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On May 26, 2005, at 12:04 PM, David Lázaro Saz wrote: On 26/05/2005, at 1:00, Adam Fedor wrote: It might be nice to fix autoconf, but then you'll run into make. 'make' doesn't like spaces in directories either - and this is a fundamental design issue. But doesn't make always run in the same directory? Anyway I'm placing this on the back burner for some time, and it's been a long time since I read the GNU make manual. But I think that this issue needs to be solved someday because directories with spaces are very common this days (Windows' "C:\Program Files", for example). I'm now deeply immersed in cross-compiling, though. I'm also reviewing how Autoconf works and how it's applied through GNUstep. My knowledge of Autoconf is somewhat superficial right now. The first problem I've detected is that the macro AC_FUNC_SETPGRP prevents cross-compiling because it always needs to run the test program that it constructs in order to check the signature of setpgrp. I haven't found how to circumvent it yet. if test $cross_compiling = no; then AC_FUNC_SETPGRP else #set a default value fi I was working on that, but the default for MingW is not what the normal default would be, but I wasn't entirely sure. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On 26/05/2005, at 1:00, Adam Fedor wrote: It might be nice to fix autoconf, but then you'll run into make. 'make' doesn't like spaces in directories either - and this is a fundamental design issue. But doesn't make always run in the same directory? Anyway I'm placing this on the back burner for some time, and it's been a long time since I read the GNU make manual. But I think that this issue needs to be solved someday because directories with spaces are very common this days (Windows' "C:\Program Files", for example). I'm now deeply immersed in cross-compiling, though. I'm also reviewing how Autoconf works and how it's applied through GNUstep. My knowledge of Autoconf is somewhat superficial right now. The first problem I've detected is that the macro AC_FUNC_SETPGRP prevents cross-compiling because it always needs to run the test program that it constructs in order to check the signature of setpgrp. I haven't found how to circumvent it yet. Cheers, David. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
On May 25, 2005, at 1:48 PM, David Lázaro Saz wrote: Hi there, I've been trying to build gnustep-make inside a separate directory. The directory where the sources are contains spaces in its name and configure fails. This seems to be a bug in autoconf. Some of the macros lack quotes (") that are needed is this where to function. Has somebody any experience with this and knows whether it can be fixed without touching autoconf, or should I simply notify the autoconf mailing list (after trying the last beta, of course)? It might be nice to fix autoconf, but then you'll run into make. 'make' doesn't like spaces in directories either - and this is a fundamental design issue. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Building in a separate directory
Hi there, I've been trying to build gnustep-make inside a separate directory. The directory where the sources are contains spaces in its name and configure fails. This seems to be a bug in autoconf. Some of the macros lack quotes (") that are needed is this where to function. Has somebody any experience with this and knows whether it can be fixed without touching autoconf, or should I simply notify the autoconf mailing list (after trying the last beta, of course)? Cheers, David. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev