Re: Compilation error on Solaris...
Am 28.04.2010 22:56, schrieb Gregory Casamento: I'm pleased to report that deleting the version of GNUstep I had at /usr/GNUstep cleared this problem. It's likely an issue with includes. It appears the code may be including the .h files from the installed version rather than the one we're building from when the installed version is available (am I describing this clearly?). I would still consider this a bug, albeit a minor one. Also, with the version of GCC I'm using, gcc 4.3.x, I'm getting a message about missing stdint.h. It's been a while since I built on Solaris, so I'm not sure if this is expected. The problem you had was with a gui file (NSGraphicsContext.m) including a base header (NSThread.h). I think in this case of two different libraries, although belonging to the same project, we would expect that the installed files get used in preference over any other version. Within the base library Richard tried to address the import issue by changing all import in implementation files to use when importing headers from the same library and started to use some #ifdef mechanism in the headers to achieve the same there: #if defined(GNUSTEP_BASE_INTERNAL) At the moment this isn't used in all base headers (and gui still lags behind, there we only have cleaned up most of the implementation files). What I don't see is how this mechanism could have helped in your case. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSToolbar and SearchView
Am 29.04.2010 00:39, schrieb Riccardo Mottola: using Grr, I notice that the search component is again displayed wrong. I had fixed that (other issues remained, but they were to be considered minor and Fred knows that we have them on the table). Did someone revert or work around my fix? It was most likely Dougs commit 30143 that broke things for you. But as you don't describe in detail what is wrong, it is hard to tell. And you must be aware of that specific fix as you corrected some C99 issues you had with it. The only change you made to toolbars that I am aware of was the _isFlexibleSpace method (By the way, your test is unneeded, the method should just return NO to get the behaviour you want. This method is overriden in the subclass). And nothing in that area has changed. On the other hand all the layout code there is just a hack, I am not surprised to see it broken by unrelated changes. We should rewrite the whole area, if ever somebody has the time for that... Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compilation error on Solaris...
On 29 Apr 2010, at 08:35, Fred Kiefer wrote: Am 28.04.2010 22:56, schrieb Gregory Casamento: I'm pleased to report that deleting the version of GNUstep I had at /usr/GNUstep cleared this problem. It's likely an issue with includes. It appears the code may be including the .h files from the installed version rather than the one we're building from when the installed version is available (am I describing this clearly?). I would still consider this a bug, albeit a minor one. Also, with the version of GCC I'm using, gcc 4.3.x, I'm getting a message about missing stdint.h. It's been a while since I built on Solaris, so I'm not sure if this is expected. The problem you had was with a gui file (NSGraphicsContext.m) including a base header (NSThread.h). I think in this case of two different libraries, although belonging to the same project, we would expect that the installed files get used in preference over any other version. Within the base library Richard tried to address the import issue by changing all import in implementation files to use when importing headers from the same library and started to use some #ifdef mechanism in the headers to achieve the same there: #if defined(GNUSTEP_BASE_INTERNAL) At the moment this isn't used in all base headers (and gui still lags behind, there we only have cleaned up most of the implementation files). What I don't see is how this mechanism could have helped in your case. Agreed ... it seems to me that it is correct behavior for gui to build using the *installed* base library. When building base, base should use its own headers, not the installed ones. When building gui, gui should use its own headers, not installed ones, and so on. But gui should use the installed base headers, and back should use installed base and gui headers. That's because base, gui, and back are all separate packages. Now, it might be nice to be able to build a core package entirely standalone without reference to installed headers, but I think that's a special case we haven't addressed ... it would presumably need a mechanism to tell gnustep-make to refrain from looking for installed headers (eg by supplying a special version of GNUstep.conf and using the environment variable to get it used instead of the default one). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: compile/link problems on linux/ppc
Hi, It's a duplication of assembler labels in inline assembler code that is used more than once. I have fixed that in svn by using a local label instead of incmodified. Code duplication occurs because GSAtomicIncrement is used in NSIncrementExtraRefCount, which is a public inline function. Thus, the compiler generates the definition of NSIncrementExtraRefCount so that other files can call it. Furthermore the function's code is expanded inline where it is used in NSObject.m, namely in the -retain method. It compiled now and seems to work, thanks. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSToolbar and SearchView
Hi, It was most likely Dougs commit 30143 that broke things for you. But as you don't describe in detail what is wrong, it is hard to tell. And you must be aware of that specific fix as you corrected some C99 issues you had with it. The search panels comes up way too small. I haven't checked precisely, but I believe it just displays at its minimum size. I admit I dod not analyze Doug's change, I just mechanically fixed compiler issues. The only change you made to toolbars that I am aware of was the _isFlexibleSpace method (By the way, your test is unneeded, the method should just return NO to get the behaviour you want. This method is overriden in the subclass). And nothing in that area has changed. On the other hand all the layout code there is just a hack, I am not surprised to see it broken by unrelated changes. We should rewrite the whole area, if ever somebody has the time for that... Yes, the code is messy and complicated, but I believe after my change reasonably correct, even if limited, since it doesn't take flexible space and resizing well in account as you well know. Understandable that some change broke the code unintended. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
