Re: includes/imports in gui.
On 19 Feb 2010, at 09:23, Fred Kiefer wrote: > Am 18.02.2010 11:47, schrieb Richard Frith-Macdonald: >> >> On 18 Feb 2010, at 10:35, Nicola Pero wrote: >> It has a small effect on how we should organize headers in base too: I want to clearly separate out non-OSX stuff from OSX stuff, so that our extensions would all be available to OSX users in the base-additions library. I was hoping to just have all the extensions headers collection in Additions.h and have Additions.h included in Foundation.h for backward compatibility ... so existing Apps which include foundation.h and expect to use our extensions would continue to be able to do so. But ... if people aren't going to want to include Foundation.h (because it's slow), perhaps the individual headers should be made to import the extensions (eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless NO_GNUSTEP is defined). Alternatively, perhaps we need to update all projects to explicitly include the headers for the extensions (irritating work to do)... I'm not sure what to do here. >>> >>> I personally vote for the option where NSString.h would import >>> GNUstepBase/NSString+GNUstepbase.h (unless NO_GNUSTEP). It >>> provides the best backwards-compatibility solution. >> >> Yeah, that's what I was thinking. Guess I'll have to do that then >> :-( > > I would like to differ. For me the best way seems to be to have the > extensions not automatically included. That will break existing > projects. (In most cases it will just cause warnings from the compiler > about methods not being defined) But it will also make clear that this > project will need to be adapted to be usable on OSX. For gui itself I am > willing to make the changes, in many cases just remove the use of the > extensions, in others just an additional include. > This is just what I think, it will be more important to get feedback > from the maintainers of GNUstep applications. If they think the clear > way is to much hassle for them, we should have the additions > automatically included. Well, I already put in the effort to keep the code backward compatible. However, we can as always, just build with NO_GNUSTEP or STRICT_MACOS_X defined. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On Fri, Feb 19, 2010 at 1:23 AM, Fred Kiefer wrote: > I would like to differ. For me the best way seems to be to have the > extensions not automatically included. That will break existing > projects. (In most cases it will just cause warnings from the compiler > about methods not being defined) But it will also make clear that this > project will need to be adapted to be usable on OSX. For gui itself I am > willing to make the changes, in many cases just remove the use of the > extensions, in others just an additional include. completely agree with this part. additions should be additions, the requirements to use them should be the same no matter what platform you're on OSX or GNUstep. it is a 180 from traditional GNUstep behavior but I would consider this change to be fixing a past mistake. > This is just what I think, it will be more important to get feedback > from the maintainers of GNUstep applications. If they think the clear > way is to much hassle for them, we should have the additions > automatically included. don't agree so much with this :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
Am 18.02.2010 11:47, schrieb Richard Frith-Macdonald: > > On 18 Feb 2010, at 10:35, Nicola Pero wrote: > >>> >>> It has a small effect on how we should organize headers in base >>> too: >>> >>> I want to clearly separate out non-OSX stuff from OSX stuff, so >>> that our extensions would all be available to OSX users in the >>> base-additions library. >>> >>> I was hoping to just have all the extensions headers collection >>> in Additions.h and have Additions.h included in Foundation.h for >>> backward compatibility ... so existing Apps which include >>> foundation.h and expect to use our extensions would continue to >>> be able to do so. >>> >>> But ... if people aren't going to want to include Foundation.h >>> (because it's slow), perhaps the individual headers should be >>> made to import the extensions (eg NSString.h would import >>> GNUstepBase/NSString+GNUstepbase.h unless NO_GNUSTEP is >>> defined). >>> >>> Alternatively, perhaps we need to update all projects to >>> explicitly include the headers for the extensions (irritating >>> work to do)... I'm not sure what to do here. >> >> I personally vote for the option where NSString.h would import >> GNUstepBase/NSString+GNUstepbase.h (unless NO_GNUSTEP). It >> provides the best backwards-compatibility solution. > > Yeah, that's what I was thinking. Guess I'll have to do that then > :-( I would like to differ. For me the best way seems to be to have the extensions not automatically included. That will break existing projects. (In most cases it will just cause warnings from the compiler about methods not being defined) But it will also make clear that this project will need to be adapted to be usable on OSX. For gui itself I am willing to make the changes, in many cases just remove the use of the extensions, in others just an additional include. This is just what I think, it will be more important to get feedback from the maintainers of GNUstep applications. If they think the clear way is to much hassle for them, we should have the additions automatically included. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On 18 Feb 2010, at 10:35, Nicola Pero wrote: >> >> It has a small effect on how we should organize headers in base too: >> >> I want to clearly separate out non-OSX stuff from OSX stuff, so that our >> extensions would all be available to OSX users in the base-additions library. >> >> I was hoping to just have all the extensions headers collection in >> Additions.h and have Additions.h included in Foundation.h for backward >> compatibility ... so existing Apps which include foundation.h and expect to >> use our extensions would continue to be able to do so. >> >> But ... if people aren't going to want to include Foundation.h (because it's >> slow), perhaps the individual headers should be made to import the extensions >> (eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless >> NO_GNUSTEP is defined). >> >> Alternatively, perhaps we need to update all projects to explicitly include >> the headers for the extensions (irritating work to do)... I'm not sure what >> to do here. >> > > > I personally vote for the option where NSString.h would import > GNUstepBase/NSString+GNUstepbase.h (unless NO_GNUSTEP). It provides the best > backwards-compatibility solution. Yeah, that's what I was thinking. Guess I'll have to do that then :-( > Just out of curiosity, in a normal build, would Additions be built before or > after gnustep-base ? Before ... since base actually links the object files from Additions (so that people don't explicitly link in the Additions library unless they are on OSX). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On 18 Feb 2010, at 10:34, Nicola Pero wrote: >> It's also worth noting that our Cocoa.h is a LOT smaller than Apple's. The >> output from gcc -E on a simple .m file that just contains the line #import >> is around 800KB on GNUstep and over 3MB with Cocoa. > > How interesting. :-) > > That suggests processing the headers in Cocoa would take almost 4x what it > takes on GNUstep (all other things being equal), > and so a precompiled header would indeed have a much larger effect on an > Apple build. > > That would explain why Apple developers are so keen on it. I couldn't really > figure out why they are so keen on precompiled headers > because when I tried them on GNUstep it was so hard to get any big > performance speedups out of them. ;-) It's also worth noting that Apple's GCC is a LOT slower than the FSF GCC. I ran some simple tests and found that FSF GCC 4.2.1 in a FreeBSD VM was around 2-4 times faster for Objective-C than Apple GCC 4.2.1 in the OS X system hosting the VM. Even with the extra overhead of the VM, the FSF version was still a lot faster. I suspect that the cost of reading the individual files is a lot higher on OS X (since it has to go via the Mach layer, where data tends to get tired and have a little rest before returning). If the first file that you compile imports Cocoa.h, then you actually get some of the benefits from PCH even if you're not using them; all of the referenced files will be in the disk cache, so the next time you try to access them you won't have to hit the disk. David -- Sent from my IBM 1620 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
It has a small effect on how we should organize headers in base too: I want to clearly separate out non-OSX stuff from OSX stuff, so that our extensions would all be available to OSX users in the base- additions library. I was hoping to just have all the extensions headers collection in Additions.h and have Additions.h included in Foundation.h for backward compatibility ... so existing Apps which include foundation.h and expect to use our extensions would continue to be able to do so. But ... if people aren't going to want to include Foundation.h (because it's slow), perhaps the individual headers should be made to import the extensions (eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless NO_GNUSTEP is defined). Alternatively, perhaps we need to update all projects to explicitly include the headers for the extensions (irritating work to do)... I'm not sure what to do here. I personally vote for the option where NSString.h would import GNUstepBase/NSString+GNUstepbase.h (unless NO_GNUSTEP). It provides the best backwards-compatibility solution. Just out of curiosity, in a normal build, would Additions be built before or after gnustep-base ? Can it be built in parallel ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
It's also worth noting that our Cocoa.h is a LOT smaller than Apple's. The output from gcc -E on a simple .m file that just contains the line #import is around 800KB on GNUstep and over 3MB with Cocoa. How interesting. :-) That suggests processing the headers in Cocoa would take almost 4x what it takes on GNUstep (all other things being equal), and so a precompiled header would indeed have a much larger effect on an Apple build. That would explain why Apple developers are so keen on it. I couldn't really figure out why they are so keen on precompiled headers because when I tried them on GNUstep it was so hard to get any big performance speedups out of them. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On 18 Feb 2010, at 08:55, Richard Frith-Macdonald wrote: > It generally doesn't matter much, but I've just gone for considering all > internal headers as objc unless they clearly have to be plain C. > In fact I should probably not have made the C/ObjC distinction since there is > really no such clear definition, and what we are really concerned about is > whether the header is meant to be included *once only* or to be included > multiple times in the same file. The vast majority of headers are in the > first category. Most C headers will work correctly with #import, but a few are designed to support multiple inclusion. For internal GNUstep headers, it doesn't matter, it's just a bad habit to get into, because eventually you'll come across that one C header that doesn't and then spend ages trying to work out why it's breaking. > Sounds reasonable ... I had no idea that support for precompiled headers was > still missing on most systems. It's worth noting that separate includes do not preclude the possibility of using precompiled headers. I'm not sure about the GCC implementation (it seems to be an ugly hack), but in Clang, a precompiled header is basically a serialised AST of the file. If you generate a precompiled header for Foundation.h and then use it as a prefix header in a file that just #imports NSObject.h, as long as the search paths are the same the compiler will skip over NSObject.h. > I'm not convinced by the other part of the argument (about precompiled > headers not being much faster), since I would expect proper support to cache > the precompiled headers (disk space is cheap) so that there would be a big > gain for some people (obviously this would vary with your pattern of use). > But an argument about performance with precompiled headers is completely > irrelevant if most people just don't have support for them. It's a big win for Apple because I/O is slow and process creation is expensive on OS X. On Windows it's probably a win too - process creation is very expensive. It's less clear on *NIX, where process creation is relatively cheap, and with flash the reduced number of random disk reads is not such an issue. It's also worth noting that our Cocoa.h is a LOT smaller than Apple's. The output from gcc -E on a simple .m file that just contains the line #import is around 800KB on GNUstep and over 3MB with Cocoa. The speed benefit from PCH is directly proportional to the size of the prefix header and, to a lesser degree, to the number of files referenced by the prefix header. David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On 18 Feb 2010, at 09:51, Nicola Pero wrote: >> I'm not convinced by the other part of the argument (about precompiled >> headers not being much faster), > > I think the problem is there is a perception that precompiled headers are > "much faster" when used. I had that perception > too, until I tried them out :-) > > Renaissance uses them, and I just looked at a random file > (GSAutoLayoutManager.m) to get some data for you. On a test > machine, compiling it without precompiled headers takes 0.61 sec, and > compiling it with precompiled headers takes 0.45 sec. > (after priming all caches etc, 10 results with mean deviation below 0.01 sec > etc). > > That is faster, but to be honest not "much faster". Using a precompiled > header reduces compile time by about 25% (note how this > is the maximum speedup you'll ever get in a build from precompiled headers). > > But, creating the precompiled header itself requires 0.8 sec (on same > machine, same conditions). > > So, to do a full build, you save 0.16 sec per file you compile, but you > consume 0.8 to generate the precompiled header first. If you compile less > than 5 files, it's not worth it. If you're doing things in parallel, you > have to multiply that, eg, if you compile with "-j 4" and your computer > can compile 4 files in parallel, precompiled headers are not worth it unless > you compile at least 20 files (since it takes 5 compilation steps > to compile 20 files, and with precompiled headers you'd save 0.16 * 5 = 0.8 > sec). So if you're using "-j 4" and compile 40 files, you'll > be looking at a compile time of 0.61s * 10 = 6.1s without precompiled > headers, and 0.8s + 0.45s * 10 = 5.3s with precompiled headers. So, > just a 14% reduction in build time over a large project with 40 files. (and > if you had, say, 24 files, you'd be looking at almost no speedup; > if you had 16 files only, you'd be looking at a slowdown!). > > All new CPUs coming on the market are 4-core CPUs. So in a couple of years > everyone will do 'make -j 4' as standard. Servers use powerful > CPUs and often are dual-CPUs; on these machines, 'make -j 8' will easily be > the minimum you do - the perception that precompiled headers are > "much faster" in that situation is an illusion. A large project will 40 > files will require 5 steps to compile with 'make -j 8', meaning using a > precompiled > header won't be any faster than building without it! Anything with less that > 32 files will simply compile slower with a precompiled header. And at the > next doubling of CPU cores, it's hard to find any Objective-C project that > will compile faster with a precompiled header. ;-) > > -- > > Of course, if you are developing, and need to recompile your code after a > change, you'd already have your precompiled header. So if you change > two files and recompile, you have to wait 0.45s instead of 0.61s for them to > be compiled. That's when precompiled headers really work great - I guess > this is the case you were referring to when you talked about precompiled > headers being "cached". And it's a very good point - in this case using a > precompiled header will always be faster. But the improvement is hard to > notice in practice. You'd be saving only 0.16s on your build. Thanks very much ... I always find real numbers (or provable reasoning from established facts) much more convincing than general statements/opinions, and that seems clear enough for even me to understand. It has a small effect on how we should organize headers in base too: I want to clearly separate out non-OSX stuff from OSX stuff, so that our extensions would all be available to OSX users in the base-additions library. I was hoping to just have all the extensions headers collection in Additions.h and have Additions.h included in Foundation.h for backward compatibility ... so existing Apps which include foundation.h and expect to use our extensions would continue to be able to do so. But ... if people aren't going to want to include Foundation.h (because it's slow), perhaps the individual headers should be made to import the extensions (eg NSString.h would import GNUstepBase/NSString+GNUstepbase.h unless NO_GNUSTEP is defined). Alternatively, perhaps we need to update all projects to explicitly include the headers for the extensions (irritating work to do)... I'm not sure what to do here. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
I'm not convinced by the other part of the argument (about precompiled headers not being much faster), I think the problem is there is a perception that precompiled headers are "much faster" when used. I had that perception too, until I tried them out :-) Renaissance uses them, and I just looked at a random file (GSAutoLayoutManager.m) to get some data for you. On a test machine, compiling it without precompiled headers takes 0.61 sec, and compiling it with precompiled headers takes 0.45 sec. (after priming all caches etc, 10 results with mean deviation below 0.01 sec etc). That is faster, but to be honest not "much faster". Using a precompiled header reduces compile time by about 25% (note how this is the maximum speedup you'll ever get in a build from precompiled headers). But, creating the precompiled header itself requires 0.8 sec (on same machine, same conditions). So, to do a full build, you save 0.16 sec per file you compile, but you consume 0.8 to generate the precompiled header first. If you compile less than 5 files, it's not worth it. If you're doing things in parallel, you have to multiply that, eg, if you compile with "-j 4" and your computer can compile 4 files in parallel, precompiled headers are not worth it unless you compile at least 20 files (since it takes 5 compilation steps to compile 20 files, and with precompiled headers you'd save 0.16 * 5 = 0.8 sec). So if you're using "-j 4" and compile 40 files, you'll be looking at a compile time of 0.61s * 10 = 6.1s without precompiled headers, and 0.8s + 0.45s * 10 = 5.3s with precompiled headers. So, just a 14% reduction in build time over a large project with 40 files. (and if you had, say, 24 files, you'd be looking at almost no speedup; if you had 16 files only, you'd be looking at a slowdown!). All new CPUs coming on the market are 4-core CPUs. So in a couple of years everyone will do 'make -j 4' as standard. Servers use powerful CPUs and often are dual-CPUs; on these machines, 'make -j 8' will easily be the minimum you do - the perception that precompiled headers are "much faster" in that situation is an illusion. A large project will 40 files will require 5 steps to compile with 'make -j 8', meaning using a precompiled header won't be any faster than building without it! Anything with less that 32 files will simply compile slower with a precompiled header. And at the next doubling of CPU cores, it's hard to find any Objective-C project that will compile faster with a precompiled header. ;-) -- Of course, if you are developing, and need to recompile your code after a change, you'd already have your precompiled header. So if you change two files and recompile, you have to wait 0.45s instead of 0.61s for them to be compiled. That's when precompiled headers really work great - I guess this is the case you were referring to when you talked about precompiled headers being "cached". And it's a very good point - in this case using a precompiled header will always be faster. But the improvement is hard to notice in practice. You'd be saving only 0.16s on your build. Thanks PS: The tests above were with Renaissance, which includes Foundation/ Foundation.h and AppKit/AppKit.h. If you try with gnustep-gui, which only needs Foundation/Foundation.h, the results are even more disappointing as the benefits of using a precompiled header are even smaller! And gnustep-gui currently tends to only #import the Foundation headers that it needs ... so the benefits from switching to #importing the entire Foundation/ Foundation.h and precompiling it are even smaller ... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
On 17 Feb 2010, at 08:25, Fred Kiefer wrote: > BTW the first file I checked in base for the new include style was > NSThread.m and this hasn't been corrected at all :-) Thanks ... I fixed that one. >> 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. It generally doesn't matter much, but I've just gone for considering all internal headers as objc unless they clearly have to be plain C. In fact I should probably not have made the C/ObjC distinction since there is really no such clear definition, and what we are really concerned about is whether the header is meant to be included *once only* or to be included multiple times in the same file. The vast majority of headers are in the first category. >> 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. Sounds reasonable ... I had no idea that support for precompiled headers was still missing on most systems. I'm not convinced by the other part of the argument (about precompiled headers not being much faster), since I would expect proper support to cache the precompiled headers (disk space is cheap) so that there would be a big gain for some people (obviously this would vary with your pattern of use). But an argument about performance with precompiled headers is completely irrelevant if most people just don't have support for them. ___ 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
Re: includes/imports in gui.
Hi, Richard Frith-Macdonald wrote: Hopefully, I've now pretty much standardised on #include for C and #import for ObjC. fine. Also, be sure that import is never used for plain C. It used to work, but on recent gcc + glibc it can lead to very very strange bugs and behavious i found out in PRICE and had to fix... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: includes/imports in gui.
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). When I implemented precompiled headers in gnustep-make, I planned to immediately modify gnustep-gui to use them. And I did. But then I discarded the work as the speed-up was too little to be worth the extra effort and complexity - not to mention all the users for whom the build would be slower because their compiler doesn't have working precompiled headers ... eg, GCC 4.1 users!. :-( Just to clarify the background - a precompiled header is specific to the exact flags you pass to the compiler. If you change any of the compiler flags, you'll need a new precompiled header. As a consequence, precompiled headers are generally used by having the project you're building (eg, gnustep-gui) have a file with all the #imports in it, and then precompile that file as part of the compilation of the project; all files in the project then include that header as the first thing they do. So, precompiled headers initially slow your build by adding an additional step ... creating the precompiled header. That step can't be parallelized because it needs to happen before all the other ones. Depending on how much using a precompiled header speeds up the following steps, it's worth it or not. If you're compiling a lot of files, and importing lots of large system headers in all these files, it's generally worth it (the more you parallelize, the less it's worth). But in the case of GUI, it's not worth it because it's only using Foundation. So it'd be only #importing Foundation/Foundation.h. In my tests it really starts to be useful when you include at least both Foundation.h and AppKit.h. Finally, most older compilers don't support precompiled headers, and GCC 4.1 has broken precompiled header support so gnustep-make automatically disables precompiled headers if you're using GCC 4.1 (for a sad example, I am using GCC 4.1). In these cases, you'll simply get a (slightly) slower build as you're including more headers than needed and they are not even precompiled. So, switching to importing Foundation/Foundation.h and precompiled headers would slow building gnustep-gui for a large group of users (who don't have a working precompiled header support in the compiler), would not significantly speed up builds for everyone else, and adds extra complexity. The current system of importing the headers we need from gnustep-base gives us consistent, fairly fast and simple builds, so I wouldn't change it. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
includes/imports in gui.
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 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. 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. 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. 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. 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). Does that seem reasonable? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
