Re: Cross-compiling GNUstep?
For Android I have been passing ./configure --host=arm-linux-androideabi. It's mentioned by configure itself. --target does look like the correct way to do it. The whole thing is slightly confusing and needs to be read a couple of times to be understood. So I did just that: http://stackoverflow.com/a/15901574/39974 http://stackoverflow.com/a/5139451/39974 On Wed Jan 01 2014 at 3:25:19 PM, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: On 29 Dec 2013, at 12:56, David Chisnall thera...@sucs.org wrote: Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? Going back to the start of thread (since it seems to have gone completely off topic), I took a quick look at the documentation (radical concept eh). The gnustep-make README document says (in the first introductory paragraph) that it supports cross compilation. The gnustep-make INSTALL document has a section on it and gives an example: ./configure --target=i386-mingw32 make install Now, I've never done any cross compilation, and probably most other people don't do it eiother, so I don't know if cross compilation support has bit-rotted, support for cross-compiling for a particular target is certainly there, ad this (the --target= option) appears to be the standard mechanism (a web search for cross compiling and autoconf finds it immediately). I guess the answer (howto do it) is that you configure for the target OS/CPU you want, then just build as normal. The INSTALL documentation also explains about using a non-flattened layout if you want to have multple architectures in the same filesystrem hierarchy etc. Of course, if there are any bit-rotted makefiles, we should correct them and make a bugfix release of the affected package. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29 Dec 2013, at 12:56, David Chisnall thera...@sucs.org wrote: Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? Going back to the start of thread (since it seems to have gone completely off topic), I took a quick look at the documentation (radical concept eh). The gnustep-make README document says (in the first introductory paragraph) that it supports cross compilation. The gnustep-make INSTALL document has a section on it and gives an example: ./configure --target=i386-mingw32 make install Now, I've never done any cross compilation, and probably most other people don't do it eiother, so I don't know if cross compilation support has bit-rotted, support for cross-compiling for a particular target is certainly there, ad this (the --target= option) appears to be the standard mechanism (a web search for cross compiling and autoconf finds it immediately). I guess the answer (howto do it) is that you configure for the target OS/CPU you want, then just build as normal. The INSTALL documentation also explains about using a non-flattened layout if you want to have multple architectures in the same filesystrem hierarchy etc. Of course, if there are any bit-rotted makefiles, we should correct them and make a bugfix release of the affected package. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 30.12.2013 07:34, schrieb Richard Frith-Macdonald: I have some little experience with CMake now ... it's a replacement for autoconf and automake (which are pretty horrible), unfortunately it's a cure which is worse than the disease. When it works, it's fine, but just like autoconf/automake, when it doesn't work or when you want to do something that hasn't been catered for, it's a nightmare and takes hours and hours to work out how things operate. Thanks for the opinion. My first impression of CMake actually aligns with this: while it has quite a number of interesting features, it's also close to be overengineered. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. I'm not sure what that means, but it sounds like a Debain packaging issue orthogonal to any issues in autoconf. At the bottom line, packaging does just four things: 1. Run the projects' prefered configuration procedure (in case of GNUstep this is ./configure). 2. Run the projects' prefered build procedure (in case of GNUstep this is make). 3. Install into a OS installation as virgin as possible (just the dependencies installed), using the projects' installation procedure. 4. Tar up the files installed by 3. Accordingly, if this doesn't work, it's very likely it doesn't work when doing the same steps manually, either. What makes packaging complicated is their insistence on working in release cycles (there's room for improvement) and the fact you always install into a virgin system (which is a good thing). BUT, as said in that other email I was probably just confused by the way tests/checks are run. They build run when invoked from Tests/, but not when invoked from (e.g.) Tests/gui/NSCell. And the lack of visible messages isn't a bug, but a feature :-} Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. My main attraction to CMake, however, is not CMake itself as much as Ninja, which dramatically improves life when doing a lot of incremental builds. LLVM has both CMake and autoconf+make build systems. After changing one file, the Ninja files that CMake generates can do an incremental build in less time than it takes for the GNU Make build system to determine that it has no work to do if you don't change any files. Oh, and when it needs to reconfigure, rerunning cmake takes about a fifth of the time that running ./configure takes, even though it's actually doing more work (configure just sets some flags for some hand-written Makefiles to use, cmake generates the build system). For OS X users, there's a nice CMake GUI that lets you generate XCode project files, which I imagine would be very attractive to users wanting to run GNUstep code on that platform. The generated XCode files aren't perfect, but they're a lot easier for OS X developers to use than GNUstep Make. Oh, and they already support building .app and .framework bundles on OS X, so it should be possible to reuse some of this code, which might even give us some existing OS X applications running on GNUstep for free... That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 30.12.2013 11:26, schrieb David Chisnall: That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. Filesystem layouts are here (and you have to support many of them): http://svn.gna.org/viewcvs/gnustep/tools/make/trunk/FilesystemLayouts/ Regarding bundle layouts, there's this: http://wiki.gnustep.org/index.php/User_FAQ#Why_not_use_framework_bundles.3F and of course this: https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/1123i-CH101-SW28 (Bundle Programming Guide) All of them mean you have to be very flexible about where to install files. Less about how to build the files. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 30 Dec 2013, at 10:26, David Chisnall thera...@sucs.org wrote: On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. Sorry for saying 'C' rather than 'C++'; didn't know that such sloppiness would offend. I looked at the source (rather than trying to find things on mailing lists) because the documentation for cmake is much less mature than that for autoconf. Yes there are rules files, but again documentation is less good/mature than that of the standard m4 macro language and shell scripts used by autoconf. I'm not sayingm there's a big difference between the two systems, just that the age difference means that it's less hard to find solutions to maintain a project using the older one. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On Mon, Dec 30, 2013 at 2:26 AM, David Chisnall thera...@sucs.org wrote: On 30 Dec 2013, at 07:23, Richard Frith-Macdonald richardfrithmacdon...@gmail.com wrote: In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. This is simply not true. The vast majority of the logic of cmake is in the .cmake files. The 'monolithic C program' (which is written in C++) is just the interpreter. Large library projects typically distribute their own .cmake files containing specific rules for their build systems, but these compose with other rules. For example, LLVM ships a bunch of .cmake files, which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and so on all ship custom .cmake files that simplify building apps for those platforms. I don't think I've ever looked at the source for CMake, though I use it for a number of projects - I've always found what I needed to do by either reading the documentation or searching their mailing list archives. My main attraction to CMake, however, is not CMake itself as much as Ninja, which dramatically improves life when doing a lot of incremental builds. LLVM has both CMake and autoconf+make build systems. After changing one file, the Ninja files that CMake generates can do an incremental build in less time than it takes for the GNU Make build system to determine that it has no work to do if you don't change any files. Oh, and when it needs to reconfigure, rerunning cmake takes about a fifth of the time that running ./configure takes, even though it's actually doing more work (configure just sets some flags for some hand-written Makefiles to use, cmake generates the build system). Yes it might be faster than autoconf/automake but it is less standardized things to do in cmake. I have played around with a cmake system in the last year and found it was horrible as the options that I needed to do for cross compiling was all different and did not always do the correct thing so I had to hack the files instead. autoconfig/automake has some nice standardized way of figuring out if an API and/or a library exists. When was the last time you did a cross of a library that was not autoconf'd? cmake was not designed for cross compiling or even fits in a GNU project. Yes autoconf has its issue (slow due to being a big shell script) but being slow helps the portability of it. Try building cmake itself, it is a hard thing to do really; worse than GCC. Thanks, Andrew Pinski For OS X users, there's a nice CMake GUI that lets you generate XCode project files, which I imagine would be very attractive to users wanting to run GNUstep code on that platform. The generated XCode files aren't perfect, but they're a lot easier for OS X developers to use than GNUstep Make. Oh, and they already support building .app and .framework bundles on OS X, so it should be possible to reuse some of this code, which might even give us some existing OS X applications running on GNUstep for free... That said, I completely agree with Fred, that there's no point discussing a change of build system without at least a proof of concept demonstration that another one would work. I would, however, suggest that this would be much easier to do if we had some documentation describing things like the various filesystem / bundle layouts. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29.12.2013 13:56, David Chisnall wrote: Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? Hi David, you probably know about our wiki page on this subject http://wiki.gnustep.org/index.php/Cross_Compiling that isn't all that helpful. I tried to cross compile GNUstep myself years ago but failed in that attempt. The two biggest issues I remember where the configure scripts and GNUstep make. We rely heavily on our configure scripts to figure out how GNUstep core components should be compiled. The best thing you can do is copy the configure scripts over to the target system and try to run them there. Of course this requires all the development tools to be installed there as well. You then have the resulting configuration files (different ones for each component when I remember correctly) that you copy back to the cross-compilation environment. You could of course rely on autoconf to sort things out for you, but it didn't work for me or try to guess everything yourself :-( The problem with GNUstep make as I remember it was that it had a somewhat different view of the host/build/target triple than any other cross compilation system I know of. As a result helper tools get compiled for the target environment but will get run during the build. The best instructions I can find at the moment are in the INSTALL file of make. Hope this helps, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
I managed to get -base cross-compiled, at least. I had to hack the GNUmakefile, because even when I tell it that it's cross compiling for a modern runtime, it correctly defines the OBJC2RUNTIME thing in the features header, but not in the GNUmakefile. I couldn't manage to persuade our autoconf stuff to pass the required [OJB]C[XX]FLAGS when trying to build things, so I had to make little wrapper scripts that invoked clang[++] with the required arguments (-B, --sysroot, -target, and so on). Note that poor cross-build support makes supporting embedded platforms difficult, and embedded these days can easily mean 1GHz CPU and 256MB of RAM. Unfortunately, this appears to be part of the legacy of autotools / GNUstep Make. David On 29 Dec 2013, at 15:20, Fred Kiefer fredkie...@gmx.de wrote: On 29.12.2013 13:56, David Chisnall wrote: Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? Hi David, you probably know about our wiki page on this subject http://wiki.gnustep.org/index.php/Cross_Compiling that isn't all that helpful. I tried to cross compile GNUstep myself years ago but failed in that attempt. The two biggest issues I remember where the configure scripts and GNUstep make. We rely heavily on our configure scripts to figure out how GNUstep core components should be compiled. The best thing you can do is copy the configure scripts over to the target system and try to run them there. Of course this requires all the development tools to be installed there as well. You then have the resulting configuration files (different ones for each component when I remember correctly) that you copy back to the cross-compilation environment. You could of course rely on autoconf to sort things out for you, but it didn't work for me or try to guess everything yourself :-( The problem with GNUstep make as I remember it was that it had a somewhat different view of the host/build/target triple than any other cross compilation system I know of. As a result helper tools get compiled for the target environment but will get run during the build. The best instructions I can find at the moment are in the INSTALL file of make. Hope this helps, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 17:06, schrieb David Chisnall: Unfortunately, this appears to be part of the legacy of autotools / GNUstep Make. My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time. What to do? Drop GNUstep Make and depend entirely on autotools? Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
By no means do I claim to have done things the right way, but it seems that work that I did plus work based on Emmanuel's patches did things right for Android. It may be worth looking through my commits around April and May 2013 into -make and -base. Then look at: http://bitbucket.org/ivucica/gnustep-android/ I never completed the work, but I tried it Thursday and: - nonupstreamed patches failed to apply due to changes in GNUstep - there was a linker error, IIRC with sysinfo(), probably because Bionic doesn't expose that. There have been some warnings and errors from configure scripts mentioning that I am incorrectly trying to cross-compile but I didn't look into that closely yet. IIRC there wasn't much need for deep 'hacking' of the build process itself (otherwise I wouldn't try to upstream it; Emmanuel's patches tried to hack a lot of things which is why they could not be applied -- they'd break other platforms). On 29 Dec 2013 16:06, David Chisnall thera...@sucs.org wrote: I managed to get -base cross-compiled, at least. I had to hack the GNUmakefile, because even when I tell it that it's cross compiling for a modern runtime, it correctly defines the OBJC2RUNTIME thing in the features header, but not in the GNUmakefile. I couldn't manage to persuade our autoconf stuff to pass the required [OJB]C[XX]FLAGS when trying to build things, so I had to make little wrapper scripts that invoked clang[++] with the required arguments (-B, --sysroot, -target, and so on). Note that poor cross-build support makes supporting embedded platforms difficult, and embedded these days can easily mean 1GHz CPU and 256MB of RAM. Unfortunately, this appears to be part of the legacy of autotools / GNUstep Make. David On 29 Dec 2013, at 15:20, Fred Kiefer fredkie...@gmx.de wrote: On 29.12.2013 13:56, David Chisnall wrote: Hello everyone, I'm trying to cross-compile GNUstep, and since I'm sure I'm not the first person to try this, I wondered if anyone had written up how to do it? I am trying to build from FreeBSD/amd64 for FreeBSD/MIPS64. I have a cross-compiler and sysroot setup. Building the runtime was trivial - just point cmake at the cross-compile toolchain file - what do I need to do for Make / base so that: - It knows that I don't actually want -make on the target platform. - I get an installed version somewhere on my local machine that I can copy to a different location on the remote - All of the correct cross-compile flags are passed to the compiler I think Ivan has been through all of this recently for Android? Hi David, you probably know about our wiki page on this subject http://wiki.gnustep.org/index.php/Cross_Compiling that isn't all that helpful. I tried to cross compile GNUstep myself years ago but failed in that attempt. The two biggest issues I remember where the configure scripts and GNUstep make. We rely heavily on our configure scripts to figure out how GNUstep core components should be compiled. The best thing you can do is copy the configure scripts over to the target system and try to run them there. Of course this requires all the development tools to be installed there as well. You then have the resulting configuration files (different ones for each component when I remember correctly) that you copy back to the cross-compilation environment. You could of course rely on autoconf to sort things out for you, but it didn't work for me or try to guess everything yourself :-( The problem with GNUstep make as I remember it was that it had a somewhat different view of the host/build/target triple than any other cross compilation system I know of. As a result helper tools get compiled for the target environment but will get run during the build. The best instructions I can find at the moment are in the INSTALL file of make. Hope this helps, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29 Dec 2013, at 17:09, Markus Hitter m...@jump-ing.de wrote: My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time. What to do? Drop GNUstep Make and depend entirely on autotools? I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. configure insists to run on a normal make and falls back to the non-fhs layout. The whole testsuite ignores messages=yes, apparently all the checks fail silently. Building a single one doesn't work either, Testing.h not found. Have yet to investigate what actually happens, but it's obvious GNUstep Make isn't exactly bullet-proof. How could backward compatibility work? I already see it has served us well for 15 years and I don't want to re-write all my projects ... Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
CMake would be great. LLVM/Clang already use it. It can generate ninja build files. It shows what it is doing with ccmake. It should make cross compiling more straight forward. And libobjc2 already uses it. hehe I tried working with those config files in base last year and found them very frustrating, refering to code and options that seemed many years old and unsupported. On Sun, Dec 29, 2013 at 1:47 PM, David Chisnall david.chisn...@cl.cam.ac.uk wrote: On 29 Dec 2013, at 17:09, Markus Hitter m...@jump-ing.de wrote: My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time. What to do? Drop GNUstep Make and depend entirely on autotools? I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29.12.2013 20:17, Markus Hitter wrote: Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. configure insists to run on a normal make and falls back to the non-fhs layout. The whole testsuite ignores messages=yes, apparently all the checks fail silently. Building a single one doesn't work either, Testing.h not found. Have yet to investigate what actually happens, but it's obvious GNUstep Make isn't exactly bullet-proof. How could backward compatibility work? I already see it has served us well for 15 years and I don't want to re-write all my projects ... Should I step in here? Looks like a nice trap, doesn't it? Oh yes, I will try it. In you last mail you wrote My impression is, GNUstep make tries to offer a very similar level of abstraction at runtime of what autoconf does at ./configure time.. No this is not what GNUstep make is trying to do. This is what we use autoconf and the generate configure file for. cmake seems to be addressing both the functionality of autoconf and GNUstep make at once. Maybe this is a good approach, I don't know and I wasn't able to find out. I skimmed over the FAQ at the cmake web site to find out about the features cmake is offering, but it didn't tell me that much. The first question that we should be asking us is what GNUstep make actually offers and how this could be replaced if we really want to replace it. GNUstep make is a tiny expansion of GNU make that allows to write more compact make files for Objective-C applications. It doesn't try to save the world and it surely has a few bugs. Now I had a few problem myself over this weekend with GNustep make. What did I do to resolve them? Suggest to switch to some new software? Or just go don't into the GNUstep make stuff and fix things? GNUstep make definitely isn't perfect. We left it to bit rot for some time. Still it is doing a lot of useful stuff which is hard to replace. I am rather sure that it would be possible to reproduce most of the features of GNUstep make with cmake and my question is not so much about the few missing case. But who would be willing to rewrite the whole of GNUstep make in cmake and guarantee full functionality? About four years ago David started to write a new libobjc based on code that was already in Etoile and with the old GNU libobjc as guideline. I would say that he is an extraordinary programmer. Still only about now would I suggest to use it on ARM or MIPS platforms. What does this tell us? Writing great software is hard, writing great software that works in environment that you yourself normally don't use is even harder. Yes, I totally agree that GNUstep make plus our configure files are very hard to use in a cross compilation case. Requesting that we throw it away and replace it by cmake would at least require a proof of concept implementation of a cmake configuration for the GNUstep core components that works flawless on let's say three Linux, two BSD and one Windows platform. If you are willing to provide that. I am going to help with testing and correcting it. And maybe in four years time we have something to replace GNUstep make. Up to then I will have to keep on fixing GNUstep make. Fred PS: The error you are getting with Testing.h suggest that you either did not install GNUstep make or didn't source the GNUstep.sh file. And messages=yes make check followed by less tests.log should give you more output that you ever would like to read through. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
Am 29.12.2013 23:11, schrieb Fred Kiefer: On 29.12.2013 20:17, Markus Hitter wrote: Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. [...] How could backward compatibility work? I already see it has served us well for 15 years and I don't want to re-write all my projects ... Should I step in here? You do and, wow, what a lengthy one. The first question that we should be asking us is what GNUstep make actually offers This is exactly the question to answer. And also, wether these advantages are important enough to justify maintaining a distinct build system. Because at the bottom line and unless I'm totally mistaken, Obj-C is compiled the same way as C, C++ and most other compiled languages. Accordingly, many other build tools should work just as fine. Could you elaborate a bit on these advantages of GNUstep Make? Writing great software is hard, writing great software that works in environment that you yourself normally don't use is even harder. Unlike libobjc2 four years ago, CMake is written already and known to work well. Accordingly, it should not be an additional burden, but a relief from some hard work. Once setup, others maintain all the build tools, GNUsteppers can concentrate on Obj-C. I'm well aware it's hard to abandon stuff one has worked on for years. But my experience is, every few years one should re-evaluate wether a competitor was much much better/faster and wether it still makes sense to continue with the own efforts. IF this evaluates to a small amount of sense, only, archiving existing stuff and enjoying the shrunken code base (less maintenance work! fewer chances for bugs!) is the right way to go. Yes, I totally agree that GNUstep make plus our configure files are very hard to use in a cross compilation case. Requesting that we throw it away and replace it by cmake would at least require a proof of concept implementation of a cmake configuration for the GNUstep core components that works flawless on let's say three Linux, two BSD and one Windows platform. I think the idea of CMake is to write build instructions once, then to deploy everywhere. Unix Makefiles, MinGW Makefiles, Xcode, whatever. CMake comes with sort of compilers to allow everybody to extract something usable for his favourite environment. This extraction wouldn't be part of GNUstep, however. And messages=yes make check followed by less tests.log should give you more output Aaah, messages are redirected into a file. Thanks for the hint! Now I see it works better than I thought previously. Many of the tests work, while quite a bunch in -gui fail due to a missing backend (no surprise). make or make check doesn't work in the individual tests, but when run from Tests/ . Cheers, Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.reprap-diy.com/ http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 29 Dec 2013, at 19:17, Markus Hitter m...@jump-ing.de wrote: Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. I have some little experience with CMake now ... it's a replacement for autoconf and automake (which are pretty horrible), unfortunately it's a cure which is worse than the disease. When it works, it's fine, but just like autoconf/automake, when it doesn't work or when you want to do something that hasn't been catered for, it's a nightmare and takes hours and hours to work out how things operate. I just see my shiny new Debian packages don't allow me to build -base without debian/rules. I'm not sure what that means, but it sounds like a Debain packaging issue orthogonal to any issues in autoconf. configure insists to run on a normal make and falls back to the non-fhs layout. I think you are talking about the case where the software hasn't been configured; you type make, and the configure script is automatically run. That's nothing directly to do with either autoconf or gnustep-make. Rather it's a deliberate feature provided by the makefiles of many (most?) projects ... if you try to build a project without having run the configure script since it was last modified, there's a makefile rule to run configure for the project (keeping any existing selected options) on your behalf (another common thing for makefiles to do is print an error message saying you haven't configured the project, and then bomb out). When you fist build a project, you are expected to run the configure script before building (with cmake, you do the same thing and run cmake before building) specifying the options you want (like the debian/fhs layout). The whole testsuite ignores messages=yes, The testsuite doesn't have a 'messages=yes' option... that's a gnustep-make option, not a test framework option. The test framework is a few header files and shell scripts and some documentation/examples, packaged as an add-on to be installed with gnustep-make so it's available anywhere you might build software using gnustep-make. It's driven by the gnustep-tests shellscript/command (so it doesn't accept any make arguments) not a make file. Each testsuite is then a hierarchy of directories containing code fragments to be built/executed to perform tests, and a files to mark which directories actually contain test code. The gnustep-tests script runs the testsuite; when building a testcase from a fragment of source code, the script may generate a makefile to do the building, and you could then manually use that makefile supplying 'messages=yes' as an argument, but such a makefile would be so simple that it's hard to see the point. apparently all the checks fail silently. Building a single one doesn't work either, Testing.h not found. That sounds lke you don't have gnustep-make and/or the testute installed? Or don't have it installed in your PATH? Given that you implied above that you didn't configure gnustep-base to use the debian filesystem layout, I expect things are installed in the gnustep layout, so I'm further guessing that you didn't set up your environment to point to the gnustep installation (sourcing GNUstep.sh is the standard way to do that), and your problem most likelyh is that the gnustep-tests script can't find things, though I'd be interested in how/where you run gnustep-tests in that case. Have yet to investigate what actually happens, but it's obvious GNUstep Make isn't exactly bullet-proof. I'm sure it's not ... but none of this sounds like gnustep-make issues. It does sound somewhat indirectly related to autoconf, in as much as it sounds like the problem is due to failure to configure, install, and set up the environment, but hard to say for sure. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cross-compiling GNUstep?
On 30 Dec 2013, at 00:19, Markus Hitter m...@jump-ing.de wrote: Am 29.12.2013 23:11, schrieb Fred Kiefer: On 29.12.2013 20:17, Markus Hitter wrote: Am 29.12.2013 19:47, schrieb David Chisnall: I'd be more inclined to move to CMake, which has the advantage of not being a complete usability disaster and being able to generate XCode projects. While I have no experience with CMake, I wouldn't mind either. [...] How could backward compatibility work? I already see it has served us well for 15 years and I don't want to re-write all my projects ... Should I step in here? You do and, wow, what a lengthy one. The first question that we should be asking us is what GNUstep make actually offers This is exactly the question to answer. And also, wether these advantages are important enough to justify maintaining a distinct build system. Because at the bottom line and unless I'm totally mistaken, Obj-C is compiled the same way as C, C++ and most other compiled languages. Accordingly, many other build tools should work just as fine. Could you elaborate a bit on these advantages of GNUstep Make? GNUstep-make is really just gnumake plus some additional structure/conventions (encapsulated in a set of make file fragments included into your project's make file) ... rather like the relationship between ObjC and C. So you can put anything from a 'normal' makefile into a gnustep make file. What makes it special are the conventions/knowledge built into it; knowledge about the different project types (command line tools, apps, libraries, frameworks), what is included with them plists etc, where they should be installed all that sort of stuff. All this knowledge is like the build-in rule in standard make that tells it how to make a .o file from a .c file (invoke the compiler with certain flags using the correct fiel names), but deals with correct linker commands, libraries, resources and where everything should go and how it should be installed. It means that the vast majority of projects essentially need to do no more than declare a few variables listing the source files used. Other projects mostly might want to add dependencies on external libraries etc, so there are variables for plugging those into all the standard rules. For the very few cases (eg libobjc2) where you are actually building something almost completely outside gnustep, then it makes sense to fall back on vanilla make rules, just using the gnustep-make rules to decide where to install the result. In these cases gnustep-make offers very little of course. Writing great software is hard, writing great software that works in environment that you yourself normally don't use is even harder. Unlike libobjc2 four years ago, CMake is written already and known to work well. Accordingly, it should not be an additional burden, but a relief from some hard work. Once setup, others maintain all the build tools, GNUsteppers can concentrate on Obj-C. If only that were true. I guess CMake is known to work well, but that's in the same sense that autoconf/automake is known to work well. When they don't do what you want, both are horrid. In my experience CMake is far more of a burden because it doesn't have the years of documentation development that autoconf has, and (more importantly to me) because its a monolithic C program. You need to get the source and figure out what it's doing, and that's just easier to do with the configure script and macros in autoconf. I guess in both cases, if you are familiar enough with them they are fine, but I don't spend all my time hacking configuration systems, so I'm perpetually unfamiliar with either. I'm also dubious about CMake's ability to integrate to GNUstep at the makefile level; With autoconf/automake we simply don't use automake, and have autoconf generate .h and .make file fragments to use in the build process. With CMake the configure/build processes are more tightly coupled ... if we can't do a similar solution then we'd probably need to hack on the CMake program itsself and maybe fork it ... making it far more work to maintain than what we have now. It's hard to see how CMake could possibly help letting us concentrate on ObjC rather than build tools, when the maintainers of CMake are no more likely to cater for GNUstep than the maintainers of autoconf/automake are. We'd just have a different project we need to supply patches to. But I guess that was Fred's point really. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
Hi, I am trying to cross-compile gnustep-make and gnustep-base and I would have some questions and remarks/feedback in this area. My goal is to be able to do an hello world using objective C on window mobile device. My current issue is the fact makefiles are adding a reference to /usr/include and it makes some conflict with includes from my toolchains: vinc...@vincent-pc:~/projects/GNUstep/gnustep-base-1.19.1$ make messages=yes target=arm-mingw32ce This is gnustep-make 2.0.8. Type 'make print-gnustep-make-help' for help. Making all in Source... make[1]: entrant dans le répertoire « /home/vincent/projects/GNUstep/gnustep-base-1.19.1/Source » Making all in subprojects of library libgnustep-base... make[2]: entrant dans le répertoire « /home/vincent/projects/GNUstep/gnustep-base-1.19.1/Source/Additions » Making all for subproject Additions... arm-mingw32ce-gcc GSCategories.m -c \ -MMD -MP -Wall -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g -fno-strict-aliasing -fgnu-runtime -I../../Headers/Additions -I../. -I../ -I../../Headers -I. -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/System/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/Local/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/lib/libffi-3.0.8/include -I/usr/include -I/home/vincent/GNUstep/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/Local/Library/Headers -I/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce/GNUstep/System/Library/Headers \ -o obj/GSCategories.m.o In file included from /home/vincent/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/windows.h:102, from ../../Headers/Additions/GNUstepBase/preface.h:51, from ../../Headers/Foundation/NSObjCRuntime.h:32, from ../../Headers/Foundation/NSObject.h:31, from ../../Headers/Foundation/FoundationErrors.h:29, from ../../Headers/Foundation/Foundation.h:33, from GSCategories.m:27: /home/vincent/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/winsock2.h:68: error: conflicting types for 'fd_set' /usr/include/sys/select.h:78: note: previous declaration of 'fd_set' was here When cross-compiling there shoudln't have -I/usr/include, in the worst case it could be $TOOLCHAIN_ROOT/usr/include with in my case TOOLCHAIN_ROOT=/home/vincent/opt/mingw32ce-4.4.0/arm-mingw32ce. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On Fri, 25 Sep 2009 15:04:21 +0200, Vincent R. foru...@smartmobili.com wrote: Hi, I wanted to try to cross-compile core foundation to be able to play with objective C on my smartphone running windows CE. I am using cegcc as a cross compiler and I have downloaded : gnustep-make-2.2.0 gnustep-base-1.19.1 What would be the necessary steps to cross-compile and/or add support for wince platform ? First question is gnustep-make architecture dependent ? I have configured and compiled gnustep-make as shown below : ./configure --prefix=/opt/mingw32ce --host=arm-mingw32ce --target=arm-mingw32ce make make instal THe problem I don't know if it handles cross-compiler and arm-*-pe targets ... Then I tried to configure gnustep-base but I get some errors that make me think that it uses wrong compiler (gcc instead of arm-mingw32ce-gcc ...) Could someone help me with this ? What makes me think it uses teh wrong compiler is the following error : Making all for subproject Additions...z Compiling file GSCategories.m ... GSCategories.m: In function `-[NSData(GSCategories) initWithHexadecimalRepresentation:]': GSCategories.m:310: warning: subscript has type `char' GSCategories.m: At top level: GSCategories.m:945: error: conflicting types for 'strerror_r' /usr/include/string.h:69: error: previous declaration of 'strerror_r' was here GSCategories.m:945: error: conflicting types for 'strerror_r' /usr/include/string.h:69: error: previous declaration of 'strerror_r' was here it seems to search for include in /usr/include while it should be in /opt/mingw32ce/arm-mingw32ce/include Last thing how does makefile works because usually when I enter make command, make file is called and processed but here this is not the case since Makefile is almost empty. So how does it work ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
OK I am progressing now I start to understand how makefiles works and now I have another error : Making all for subproject unix... Compiling file GSRunLoopCtxt.m ... GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt dealloc]': GSRunLoopCtxt.m:84: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:84: error: (Each undeclared identifier is reported only once GSRunLoopCtxt.m:84: error: for each function it appears in.) GSRunLoopCtxt.m:88: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:92: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt endEvent:for:]': GSRunLoopCtxt.m:136: error: 'ET_RDESC' undeclared (first use in this function) GSRunLoopCtxt.m:137: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:139: error: 'ET_WDESC' undeclared (first use in this function) GSRunLoopCtxt.m:140: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:142: error: 'ET_EDESC' undeclared (first use in this function) GSRunLoopCtxt.m:143: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt initWithMode:extra:]': GSRunLoopCtxt.m:200: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:202: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:204: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m: In function '-[GSRunLoopCtxt pollUntil:within:]': GSRunLoopCtxt.m:741: error: '_efdMap' undeclared (first use in this function) GSRunLoopCtxt.m:742: error: '_rfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:743: error: '_wfdMap' undeclared (first use in this function) GSRunLoopCtxt.m:748: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:776: error: 'ET_EDESC' undeclared (first use in this function) GSRunLoopCtxt.m:784: error: 'ET_RDESC' undeclared (first use in this function) GSRunLoopCtxt.m:792: error: 'ET_WDESC' undeclared (first use in this function) GSRunLoopCtxt.m:774: warning: enumeration value 'ET_HANDLE' not handled in switch GSRunLoopCtxt.m:774: warning: enumeration value 'ET_WINMSG' not handled in switch GSRunLoopCtxt.m:856: error: 'errno' undeclared (first use in this function) GSRunLoopCtxt.m:856: error: 'EINTR' undeclared (first use in this function) GSRunLoopCtxt.m:1011: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m: In function '+[GSRunLoopCtxt awakenedBefore:]': GSRunLoopCtxt.m:1080: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:1080: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' GSRunLoopCtxt.m:1081: error: 'struct GSRunLoopThreadInfo' has no member named 'inputFd' make[4]: *** [obj/GSRunLoopCtxt.m.o] Error 1 make[3]: *** [internal-subproject-all_] Error 2 Why is it compiling subproject unix ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On 25 Sep 2009, at 16:57, Vincent R. wrote: Why is it compiling subproject unix ? This will have been set by the configure script. Did you set target triple when you ran ./configure? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On Fri, 25 Sep 2009 16:59:41 +0100, David Chisnall thera...@sucs.org wrote: On 25 Sep 2009, at 16:57, Vincent R. wrote: Why is it compiling subproject unix ? This will have been set by the configure script. Did you set target triple when you ran ./configure? David I found why I think : ifeq ($(GNUSTEP_TARGET_OS), mingw32) libgnustep-base_SUBPROJECTS+=win32 else libgnustep-base_SUBPROJECTS+=unix endif and since I am using mingw32ce it's not matched... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: cross compiling gnustep on embedded device (wince)
On 25 Sep 2009, at 17:06, Vincent R. wrote: On Fri, 25 Sep 2009 16:59:41 +0100, David Chisnall thera...@sucs.org wrote: On 25 Sep 2009, at 16:57, Vincent R. wrote: Why is it compiling subproject unix ? This will have been set by the configure script. Did you set target triple when you ran ./configure? David I found why I think : ifeq ($(GNUSTEP_TARGET_OS), mingw32) libgnustep-base_SUBPROJECTS+=win32 else libgnustep-base_SUBPROJECTS+=unix endif and since I am using mingw32ce it's not matched... You can try just tweaking it to match on mingw32ce too, but I don't think anyone else has tested it on a Wince machine, so you may need to do some tweaking to make it work if you get any errors. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
