Re: libobjc2
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
libobjc2
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. Thanks ___ 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
[PATCH] GSXML: Respect XML catalogs
Hello guys,
some months back, somebody complained that gnustep-base took ages for
them to build on a machine without network access. The problem was that
the gsdoc DTDs were not yet installed and autogsdoc was trying to fetch
them over the net, making it wait for a timeouts quite a while.
libxml2 does support a feature called xml-catalogs for such situations,
allowing you to remap xml PUBLIC/SYSTEM identifiers to new (local)
urls.
Recently, I took a look at GSXML and how it does handle DTD resolution.
It turns out that it is overriding DTD resolution in a manner that
bypasses catalogs. If a DTD is not installed to a location we explicitly
search, it will always be fetched from the original url. Attached is a
patch that corrects that by adding the DTDs GNUstep is resolving
internally to the catalog and running libxml2's builtin lookup function
afterwards. In theory, this should not break anything, but as always I
might have screwed up slightly somewhere.
Cheers,
Niels
Index: Source/Additions/GSXML.m
===
--- Source/Additions/GSXML.m (revision 29650)
+++ Source/Additions/GSXML.m (working copy)
@@ -77,6 +77,7 @@
#include
#include
#include
+#include
#ifdef HAVE_LIBXML_SAX2_H
#include
#else
@@ -84,6 +85,7 @@
# define xmlSAX2GetLineNumber getLineNumber
# define xmlSAX2GetPublicId getPublicId
# define xmlSAX2GetSystemId getSystemId
+# define xmlSAX2ResolveEntity resolveEntity
#endif
#include
#include
@@ -154,6 +156,7 @@
{
cacheDone = YES;
xmlMemSetup(objc_free, objc_malloc, objc_realloc, objc_strdup);
+ xmlInitializeCatalog();
#if HAVE_LIBXML_SAX2_H
xmlDefaultSAXHandlerInit();
@@ -2417,9 +2420,7 @@
loadEntityFunction(void *ctx,
const unsigned char *eid, const unsigned char *url)
{
- extern xmlParserInputPtr xmlNewInputFromFile();
NSString *file = nil;
- xmlParserInputPtr ret = 0;
NSString *entityId;
NSString *location;
NSArray *components;
@@ -2428,10 +2429,10 @@
unsigned index;
NSCAssert(ctx, @"No Context");
- if (url == 0)
-return 0;
+ if (url == NULL)
+return NULL;
- entityId = (eid != 0) ? (id)UTF8Str(eid) : nil;
+ entityId = (eid != NULL) ? (id)UTF8Str(eid) : nil;
location = UTF8Str(url);
components = [location pathComponents];
local = (NSMutableString *) [NSMutableString string];
@@ -2574,51 +2575,24 @@
ofType: @""
inDirectory: @"DTDs"];
}
- if (file == nil)
- {
- NSURL *aURL;
-
- aURL = [NSURL URLWithString: location];
- if ([aURL isFileURL] == YES)
- {
- file = [aURL path];
- }
- else
- {
- NSData *data = [aURL resourceDataUsingCache: NO];
-
- if ([data length] > 0)
- {
- file = [@"/tmp" stringByAppendingPathComponent: local];
- [data writeToFile: file atomically: NO];
- }
- }
- }
}
}
+ /*
+ * If we found the DTD somewhere, add it to the catalog.
+ */
if ([file length] > 0)
{
- const char *path;
-
-#if defined(__MINGW32__)
- /*
- * The xmlNewInputFromFile() function requires an eight bit string
- * but on a modern windows filesystem the file name could be unicode
- * which can't be represented as a cString ... and may cause an
- * exception ... nothing we can do about it really.
- */
- path = [file cString];
-#else
- path = [file fileSystemRepresentation];
-#endif
- ret = xmlNewInputFromFile((xmlParserCtxtPtr)ctx, path);
+ NSURL *theURL = [NSURL fileURLWithPath: file];
+ xmlCatalogAdd((const unsigned char*)"public", eid,
+UTF8STRING([theURL absoluteString]));
}
- else
-{
- NSLog(@"don't know how to load entity '%s' id '%s'", url, eid);
-}
- return ret;
+
+ /*
+ * A local DTD will now be in the catalog: The builtin entity resolver can
+ * take over.
+ */
+ return xmlSAX2ResolveEntity(ctx, eid, url);
}
signature.asc
Description: Digital signature
___
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
Re: Compiler warnings with the new base code
Hi! I get those warnings too. First I thought it was gcc 4.2's rather messed up alias-analysis, but since Fred uses 4.4.1 that would not be the case. Maybe -fno-strict-aliasing has to be added to the compiler flags... Cheers TOM Zitat von Fred Kiefer : After the reorganisation of base I get a lot more compiler warnings then before. It would be great if somebody could look into these. I am using gcc 4.4.1 on a 64 bit system. Compiling file GSObjCRuntime.m ... GSObjCRuntime.m: In function ‘GSObjCMethodNames’: GSObjCRuntime.m:154: warning: dereferencing type-punned pointer will break strict-aliasing rules GSObjCRuntime.m:154: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from GSObjCRuntime.m:1212: ../../Headers/Additions/GNUstepBase/GSIMap.h: In function ‘GSIMapCountByEnumeratingWithStateObjectsCount’: ../../Headers/Additions/GNUstepBase/GSIMap.h:981: warning: dereferencing type-punned pointer will break strict-aliasing rules GSObjCRuntime.m: In function ‘GSObjCMethodNames’: GSObjCRuntime.m:154: warning: dereferencing pointer ‘iterator.78’ does break strict-aliasing rules GSObjCRuntime.m:154: note: initialized from here Compiling file NSInvocation+GNUstepBase.m ... NSInvocation+GNUstepBase.m:32:2: warning: #warning (steph...@sente.ch) Not implemented NSInvocation+GNUstepBase.m:38:2: warning: #warning (steph...@sente.ch) Not implemented Shouldn't we just remove these methods? Extensions that aren't implemented don't look to useful. Compiling file NSArray.m ... NSArray.m: In function ‘-[NSArray countByEnumeratingWithState:objects:count:]’: NSArray.m:397: warning: cast to pointer from integer of different size If David's book is correct, than this is the wrong way to deal with the mutations pointer. David could you please have a look? Compiling file NSConcreteHashTable.m ... NSConcreteHashTable.m: In function ‘-[NSConcreteHashTable countByEnumeratingWithState:objects:count:]’: ../Headers/Additions/GNUstepBase/GSIMap.h:926: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:926: note: initialized from here ../Headers/Additions/GNUstepBase/GSIMap.h:928: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:928: note: initialized from here NSConcreteHashTable.m: In function ‘NSCompareHashTables’: ../Headers/Additions/GNUstepBase/GSIMap.h:926: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:926: note: initialized from here ../Headers/Additions/GNUstepBase/GSIMap.h:928: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:928: note: initialized from here ../Headers/Additions/GNUstepBase/GSIMap.h:926: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:926: note: initialized from here ../Headers/Additions/GNUstepBase/GSIMap.h:928: warning: dereferencing pointer ‘enumerator.71’ does break strict-aliasing rules ../Headers/Additions/GNUstepBase/GSIMap.h:928: note: initialized from here There are plenty more of these... Compiling file NSDistantObject.m ... NSDistantObject.m: In function ‘-[NSDistantObject methodSignatureForSelector:]’: NSDistantObject.m:728: warning: call to function ‘GSDescriptionForInstanceMethod’ without a real prototype NSDistantObject.m:727: note: ‘GSDescriptionForInstanceMethod’ was declared here NSDistantObject.m:740: warning: call to function ‘GSDescriptionForClassMethod’ without a real prototype NSDistantObject.m:739: note: ‘GSDescriptionForClassMethod’ was declared here This is an old one. Compiling file NSException.m ... NSException.m: In function ‘-[GSStackTrace init]’: NSException.m:596: warning: cast from pointer to integer of different size NSException.m: In function ‘-[GSStackTrace symbols]’: NSException.m:621: warning: cast to pointer from integer of different size Another old one. Compiling file NSHashTable.m ... NSHashTable.m: In function ‘-[NSHashTable count]’: NSHashTable.m:145: warning: cast from pointer to integer of different size NSHashTable.m: In function ‘-[NSHashTable countByEnumeratingWithState:objects:count:]’: NSHashTable.m:152: warning: cast from pointer to integer of different size And once more an old one. Compiling file NSMapTable.m ... NSMapTable.m: In function ‘-[NSMapTable count]’: NSMapTable.m:140: warning: cast from pointer to integer of different size NSMapTable.m: In function ‘-[NSMapTable countByEnumeratingWithState:objects:count:]’: NSMapTable.m:147: warning: cast from pointer to integer of different size Compiling file NSNumber.m ... NSNumber.m: In function ‘-[NSNumber pointerValue]’: NSNumber.m:567: warning: cast to pointer from integer of different size Compiling file NSPortCoder.m ...
