Re: error while compiling base
On 17 Feb 2010, at 23:03, David Chisnall wrote: > On 17 Feb 2010, at 22:44, Richard Frith-Macdonald wrote: > >> No, it's a typo made when converting from using the old, reliable, >> LONG_LONG_MAX (basically worked on every platform except perhaps BSD, and >> used to be the default but is now the fallback mechanism) to the newer c99 >> standard (which works on most modern platforms and is now the default, but >> used to be the fallback mechanism). > > Ah, fair enough. > >> I know you are a BSD person, but the reality is that GNUstep is GNU software >> and uses the GNU compiler (GCC) ... so saying something 'will break anywhere >> except GNU platforms' is actually pretty close to saying that it will break >> anywhere that GNUstep doesn't run, and sounds perilously like a religious >> argument. > > > Not at all. It's from limits.h, which is provided by libc. The C standard > defines LLONG_MAX. It does ... but even now, not all systems conform to the current standard ... and I think this code dates from before the standard (before my time anyway)! > GNU libc and HP-UX libc define LONG_LONG_MAX, but most other libc's that I > checked don't. AIX defines LONGLONG_MAX, others define their own flavour, in > addition to the standard LLONG_MAX. Both the long long type and the > LLONG_MAX macro in limits.h were defined at the same time, as part of C99. Sure, but the type (and the gnu macro) pre-date the standard. I expect the code originally used LONG_LONG_MAX as the de-facto standard at the time it was written. > GCC, on the other hand, has a built-in __LONG_LONG_MAX__, which is set by the > compiler based on the target triple and is used on some libc versions to > initialise LLONG_MAX. I'd have no problems with your using > __LONG_LONG_MAX__, since, as far as I know, this works on all existing > Objective-C compilers that support a long long data type. Let's do that then. > Unless I'm mistaken, GNUstep runs on a lot of non-GNU platforms. If this > isn't the case, maybe someone should delete some of the 11 listed here (not > counting duplicates for different versions or CPU architectures): > > http://gnustep.org/resources/documentation/User/GNUstep/machines_toc.html In terms of support for LONG_LONG_MAX that breaks down to bsd platforms and ones which support LONG_LONG_MAX (linux and mingw/cygwin windows) with solaris being a strange case which has changed from being bsd to sysv over the years and really tends to build with almost an entire gnu toolchain. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error while compiling base
On 17 Feb 2010, at 22:44, Richard Frith-Macdonald wrote: > No, it's a typo made when converting from using the old, reliable, > LONG_LONG_MAX (basically worked on every platform except perhaps BSD, and > used to be the default but is now the fallback mechanism) to the newer c99 > standard (which works on most modern platforms and is now the default, but > used to be the fallback mechanism). Ah, fair enough. > I know you are a BSD person, but the reality is that GNUstep is GNU software > and uses the GNU compiler (GCC) ... so saying something 'will break anywhere > except GNU platforms' is actually pretty close to saying that it will break > anywhere that GNUstep doesn't run, and sounds perilously like a religious > argument. Not at all. It's from limits.h, which is provided by libc. The C standard defines LLONG_MAX. GNU libc and HP-UX libc define LONG_LONG_MAX, but most other libc's that I checked don't. AIX defines LONGLONG_MAX, others define their own flavour, in addition to the standard LLONG_MAX. Both the long long type and the LLONG_MAX macro in limits.h were defined at the same time, as part of C99. GCC, on the other hand, has a built-in __LONG_LONG_MAX__, which is set by the compiler based on the target triple and is used on some libc versions to initialise LLONG_MAX. I'd have no problems with your using __LONG_LONG_MAX__, since, as far as I know, this works on all existing Objective-C compilers that support a long long data type. Unless I'm mistaken, GNUstep runs on a lot of non-GNU platforms. If this isn't the case, maybe someone should delete some of the 11 listed here (not counting duplicates for different versions or CPU architectures): http://gnustep.org/resources/documentation/User/GNUstep/machines_toc.html This is contrasted with just GNU/Linux listed on the same page, although I did manage to get GNUstep running on GNU/OpenSolaris a while ago, and I believe others have run it on GNU HURD. We probably also work on GNU/kFreeBSD, meaning that we only support about three times as many non-GNU platforms as GNU platforms. David -- Sent from my IBM 1620 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error while compiling base
On 17 Feb 2010, at 20:32, David Chisnall wrote: > On 17 Feb 2010, at 20:23, Riccardo Mottola wrote: > >> WHen compiling base I now get: >> >> Compiling file GSFormat.m ... >> GSFormat.m:62:2: error: #error handle_llong_max defined without llong_max >> being defined > > This seems to be a bug where Richard is using the non-standard LONG_LONG_MAX > instead of the C99 standard LLONG_MAX. No, it's a typo made when converting from using the old, reliable, LONG_LONG_MAX (basically worked on every platform except perhaps BSD, and used to be the default but is now the fallback mechanism) to the newer c99 standard (which works on most modern platforms and is now the default, but used to be the fallback mechanism). > LONG_LONG_MAX is a GNUism, and will break anywhere except GNU platforms (and > HP-UX, which, I think, is where GNU copied it from). I know you are a BSD person, but the reality is that GNUstep is GNU software and uses the GNU compiler (GCC) ... so saying something 'will break anywhere except GNU platforms' is actually pretty close to saying that it will break anywhere that GNUstep doesn't run, and sounds perilously like a religious argument. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error while compiling base
On 17 Feb 2010, at 20:23, Riccardo Mottola wrote: > WHen compiling base I now get: > > Compiling file GSFormat.m ... > GSFormat.m:62:2: error: #error handle_llong_max defined without llong_max > being defined This seems to be a bug where Richard is using the non-standard LONG_LONG_MAX instead of the C99 standard LLONG_MAX. LONG_LONG_MAX is a GNUism, and will break anywhere except GNU platforms (and HP-UX, which, I think, is where GNU copied it from). If we're going to support non-standard versions of this, we should also test for LONGLONG_MAX, which is what AIX uses. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
error while compiling base
WHen compiling base I now get: Compiling file GSFormat.m ... GSFormat.m:62:2: error: #error handle_llong_max defined without llong_max being defined I get this both on FreeBSD/x86 with gcc 4.2.1 as well as on OpenBSD/sparc with gcc 2.95 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libobjc2
On Wed, 17 Feb 2010 10:48:38 +, David Chisnall wrote: > On 17 Feb 2010, at 06:45, Richard Frith-Macdonald wrote: > >> >> On 17 Feb 2010, at 00:12, Vincent Richomme wrote: >> >>> Hi, >>> >>> I would like to compile libobjc2 on msys/mingw but I don't know anything >>> to GNUstep build system. >>> I have installed GNustep with installer provided on your website but >>> now I >>> would like >>> to know how to instruct makefiles to use clang. >> >> You set the CC environment variable to be 'clang' >> >> eg. >> CC=clang make >> >> Good luck. I;m sure that people (David in particular) will be >> interested in hearing how you get on. > > Definitely! As far as I know, no one has tested libobjc2 on Windows yet, > so it would be great to get some feedback. > > Of course, because you're the first one doing the testing, you'll probably > find lots of things that don't work. Let me know when you do... Ok so the first problem is to compile clang compiler with current msys/mingw provided by GNUstep installer(0.24.0). I tried and I get the following error about symboloc link : llvm[4]: Creating Release Alias clang++ (without symbols) ln: creating symbolic link `/home/Vincent/llvm/obj/Release/bin/clang++.exe' t o `clang.exe': No such file or directory When looking at bin directory I do have a clang.exe binary and I have ln. I also tried to create it manually and ir works... So the first task is to understand why it doesn't work with your msys/mingw. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libobjc2
On 17 Feb 2010, at 06:45, Richard Frith-Macdonald wrote: > > On 17 Feb 2010, at 00:12, Vincent Richomme wrote: > >> Hi, >> >> I would like to compile libobjc2 on msys/mingw but I don't know anything >> to GNUstep build system. >> I have installed GNustep with installer provided on your website but now I >> would like >> to know how to instruct makefiles to use clang. > > You set the CC environment variable to be 'clang' > > eg. > CC=clang make > > Good luck. I;m sure that people (David in particular) will be interested in > hearing how you get on. Definitely! As far as I know, no one has tested libobjc2 on Windows yet, so it would be great to get some feedback. Of course, because you're the first one doing the testing, you'll probably find lots of things that don't work. Let me know when you do... David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
Am 16.02.2010 15:53, schrieb Richard Frith-Macdonald: > I'd like to standardise include/imports in the core libraries ... as > I've been doing a lot of it in base. > > Previously in base, there was really a bit of a mess ... > > Lots of #includes from they days when #import was deprecated ... > harmless but annoying Over the last few years I started to change this in all the gui files I touched. Perhaps it is the time to be more thorough on this. BTW the first file I checked in base for the new include style was NSThread.m and this hasn't been corrected at all :-) > A mixture of and "foo.h" used ... not harmless ... anything > using the angle brackets could pick up installed headers rather than > the local/new versions, which could cause problems for anyone > building from a new release or from svn. Angle brackets should only be used for external stuff, that is all the C headers and of course Foundation headers when used in gui. > Foundation/Foundation.h used in some places, individual files used in > others... because Foundation.h imports all the other headers, using > it while building base would also cause installed headers to be used > when you actually want local ones. In gui only a few places import AppKit.h and these have annoyed me for a long time. These files will be recompiled every time anything changes. > Two or more files (at least GNUstep.h and GSCategories.h) needed to > be included/imported by OSX apps wanting to use base additions, and > some of those headers caused problems it used from within gnustep > code. > > Hopefully, I've now pretty much standardised on #include for C and > #import for ObjC. Fine by me, but what do we count as being C? gui currently sees the config.h file as C and therefore we use #include. > All source in base should now use quotes rather than angle brackets, > and avoid Foundation.h so that new builds should work properly on > systems where base is already installed. > > There should be a single header 'GNUstepBase/Additions.h' for > software on OSX using the Apple Foundation, and this file should be > safe to include on GNUstep systems (indded, Foundation.h on GNUstep > should import it unless NO_GNUSTEP is defined). Actually, I need to > re-port the additions library to OSX ... it's currently broken > there. At the moment there isn't any gui Addition code that could be use on OSX, although there are a few classes that would be worth it. > Anyway, given that gnustep-make and recent compilers have supported > precompiled headers for some time now, I think gui/back should > probably simplified to just do #import > (assuming that 'startup' installs base before it builds gui ... so > the installed Foundation.h will point to all the right code and will > have a precompiled version to make for fast compilation of gui and > back). Here I agree with Nicola. Support for pre-compilation is not that widespread that we should enforce it. And including Foundation.h instead of single header files could make compilation slower in some cases. I think, in this case I will leave the gui includes just as they are, when we include Foundation.h fine, when it is broken up in single files, fine as well. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
