Re: Next release
Hi, On 2008-03-02 00:18:47 +0100 Adam Fedor <[EMAIL PROTECTED]> wrote: It's time for another release. I'll make an unstable release of the core libraries late next week. I also plan a stable base release, but I will not make a stable release of the gui libraries, unless there is some important patch the someone wants there (or better yet, patch the stable branch yourself so I don't have to do it). I know of no blocking issues, I should probably give a compile test on gcc 2.95 in the next days, just to be sure. About stable, since I gather Debian tracks stable (?) it would be nice to have some of the printing stuff backported to stable: PRICE doesn't compile against current debian packages. But it is just my guess: htey have an reasonably up to date base, but a horrid old gui and I thought it was that they track stable. Let me know if there is some reason I should wait. It would have been nice to have more information about bug 22373 and maybe a fix before release, but I think it can't be considered blocking. Since no one else reported it, it might be SPARC specific. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 2, 2008, at 3:51 AM, Riccardo wrote: About stable, since I gather Debian tracks stable (?) it would be nice to have some of the printing stuff backported to stable: PRICE doesn't compile against current debian packages. But it is just my guess: htey have an reasonably up to date base, but a horrid old gui and I thought it was that they track stable. Debian stable has pretty old stuff. The Debian testing release has our latest "stable" packages, which I am now noticing are almost a year old (from initial release). Perhaps we could think about making a new stable branch... Although (my two cents), the "unstable" label is a bit of a misnomer, in the vast majority of cases, you could probably install any new unstable release, and your old apps would work fine without a recompile (aside from the so name change). Although we could do a little better with ABI compatibility, for the most part, only API changes happen in the unstable branch... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Sun, Mar 2, 2008 at 7:35 PM, Adam Fedor <[EMAIL PROTECTED]> wrote: > > On Mar 2, 2008, at 3:51 AM, Riccardo wrote: > > About stable, since I gather Debian tracks stable (?) it would be > > nice to have some of the printing stuff backported to stable: PRICE > > doesn't compile against current debian packages. But it is just my > > guess: htey have an reasonably up to date base, but a horrid old gui > > and I thought it was that they track stable. > > Debian stable has pretty old stuff. The Debian testing release has > our latest "stable" packages, which I am now noticing are almost a > year old (from initial release). Perhaps we could think about making a > new stable branch... Debian Unstable (Sid) tends to only track stable packages of anything! The so called "unstable" Debian branch is just unstable due to package problems, but the packages in it are generally the latest stable (assuming there's someone maintaining them). > Although (my two cents), the "unstable" label is a bit of a misnomer, > in the vast majority of cases, you could probably install any new > unstable release, and your old apps would work fine without a > recompile (aside from the so name change). Although we could do a > little better with ABI compatibility, for the most part, only API > changes happen in the unstable branch... > I'd really like to see that! ABI compatibility goes a long way, specially when GNUstep starts having more applications built around it. At the moment it's already a chore trying to rebuild everything (off the top of my head I need at least 10 apps/frameworks just to do basic stuff). Of course, there's always that balancing act between keeping up with Cocoa or updating the API and keeping ABI compatibility. Seeing as I don't understand ObjC enough to know what brakes ABI, I guess I'm just talking out of my ass, but I still think there should be more stable releases before moving on (at the current state there were 2 GUI/Back releases and 3 Base). Just my opinion on this issue, I know it's way off topic and has been discussed more than it should have. Sorry so bringing it up again... Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Next release
> It's time for another release. Btw, gnustep-make is also ready for release - I suppose it could be called 2.0.5. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Sun, 02 Mar 2008 11:51:01 +0100, Riccardo <[EMAIL PROTECTED]> said: > Hi, > On 2008-03-02 00:18:47 +0100 Adam Fedor <[EMAIL PROTECTED]> wrote: > It's time for another release. I'll make an unstable release of the core >> libraries late next week. I also plan a stable base release, but I >> will not make a stable release of the gui libraries, unless there is >> some important patch the someone wants there (or better yet, patch >> the stable branch yourself so I don't have to do it). > I know of no blocking issues, I should probably give a compile test on > gcc 2.95 in the next days, just to be sure. About stable, since I > gather Debian tracks stable (?) it would be nice to have some of the > printing stuff backported to stable: PRICE doesn't compile against > current debian packages. But it is just my guess: htey have an > reasonably up to date base, but a horrid old gui and I thought it was > that they track stable. Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? Hubert (with his Debian Developer hat on) -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Stefan Bidigaray wrote: > Debian Unstable (Sid) tends to only track stable packages of anything! > The so called "unstable" Debian branch is just unstable due to package > problems, but the packages in it are generally the latest stable > (assuming there's someone maintaining them). Yes, that is usually true. (A few packages may track the unstable branch, e.g. the GNUMail package, which is based off a daily snapshot. But for the most part, packages in Debian sid track stable branches.) Occasionally, unstable branches can be tracked in Debian experimental. I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. By the way, if anyone wants to help with GNUstep packages, we can always use help. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Hi, On 2008-03-02 21:00:53 +0100 Hubert Chathi <[EMAIL PROTECTED]> wrote: Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? I cannot tell for sure, but PRICE had little changes since the past release, so it should compile. It misses some printing stuff which was probably added later. I guess it can be backported to stable. A newer stable release should be done indeed. Adam? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote: I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. I think tracking unstable would be a good idea. Are you having general problems with libffi/ffcall or on a particular platform? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 3, 2008, at 1:40 PM, Riccardo wrote: A newer stable release should be done indeed. Adam? That's up to Gregory, et. al. Do we have any goals for the next stable release? gui 1.0? That last stable release, I didn't start backporting patches until six months afterwards, when it was impossible to catch up. This time I'll be more on top of things, so the branches should track better, hopefully. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Adam Fedor wrote: > > On Mar 3, 2008, at 1:40 PM, Riccardo wrote: > >> >> A newer stable release should be done indeed. Adam? >> > That's up to Gregory, et. al. Do we have any goals for the next stable > release? gui 1.0? > I am still a bit reluctant to use the version number 1.0. We would be committing us to stay ABI compatible from then on and we are not ready for that. Using the number 0.14.0 would be fine for me. (I already have a proposal for ABI stability, I just need time to write it up and then find somebody to implement it :-) Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Adam Fedor wrote: >> On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote: >>> >> I was intending on tracking the GNUstep unstable branch in Debian >> experimental, but we currently have some unresolved issues regarding >> ffcall/libffi. > I think tracking unstable would be a good idea. OK, I will work on getting unstable in. > Are you having general problems with libffi/ffcall or on a particular > platform? Well, ffcall, as you know, doesn't work properly on SELinux, PAX, etc. I had a report of libffi not working on x86_64 (see one of my previous messages), and I don't have proper access to an x86_64 box to debug. So it seems like neither solution will work in general for all users. I'm working a solution to provide both versions in Debian, but it'll be a bit before I can implement it, due to lack of time. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 5, 2008, at 9:51 AM, Hubert Chathi wrote: Well, ffcall, as you know, doesn't work properly on SELinux, PAX, etc. I had a report of libffi not working on x86_64 (see one of my previous messages), and I don't have proper access to an x86_64 box to debug. So it seems like neither solution will work in general for all users. It would be nice to be able to standardize on one, but unfortunately, you still have to figure out which ones work on each machine. libffi seems to be more actively expanding the architectures it runs on. Although it appears that recently ffcall has been split off from clisp and may be more actively maintained - it now has a page at savannah and has been renamed libffcall. There's also a bug report regarding SELinux, etc there, so perhaps it could be fixed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Adam/Fred, One of the things I think we need to do in order to address the ABI compatibility issue is to adopt a strategy similar to what Apple has done in it's headers. Currently there is a lot of space which is marked as "reserved" in Apple's header files. This allows for future additions without changing the memory layout of the class which is what leads to ABI issues and subsequently the need for recompilation. This would allow older versions of applications to continue to function with newer versions of the core libraries even after a modification where some of the "reserved" space has been consumed. The trick is to reserve just the right amount of space so that you don't make your classes needlessly big and so that you adequately anticipate the future growth of some. Another potential solution to this problem, a bit different from the one above and probably a little risky is to simply have a void pointer in each class' ivar section and have it point to the appropriate structure when initialized during runtime. This would allow the ABI to be stable since the class' foot print would always be the size of the void pointer. The structure could then be changed to our hearts content without need to worry about ABI compatibility issues at all. The drawback to this one is that it's a major undertaking to implement it and, it's, potentially hazardous. The third option is to get gui to a point where it's ABI is actually stable. Consider that base hasn't changed much for a long time. This is because it's been at 1.0 for a very long time and because it is truly stable. There are a myriad of things we need to focus on in gui at this point before we can, rightfully, call it a 1.0 release. Printing is the one thing that I think is most prominent on my mind regarding gui at this point. Printing is incomplete. Last time I started up TextEdit.app or Ink.app and typed and tried to print a page, it came out blank. This could be a configuration issue, or it could be something else, I don't know.. if it is, please tell me. :) Anyway... I'll come back later and we can discuss what gui 1.0 should be. :) Later, GJC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: Adam Fedor <[EMAIL PROTECTED]> Cc: Developer GNUstep Sent: Tuesday, March 4, 2008 1:37:49 PM Subject: Re: Next release Adam Fedor wrote: > > On Mar 3, 2008, at 1:40 PM, Riccardo wrote: > >> >> A newer stable release should be done indeed. Adam? >> > That's up to Gregory, et. al. Do we have any goals for the next stable > release? gui 1.0? > I am still a bit reluctant to use the version number 1.0. We would be committing us to stay ABI compatible from then on and we are not ready for that. Using the number 0.14.0 would be fine for me. (I already have a proposal for ABI stability, I just need time to write it up and then find somebody to implement it :-) Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
I would love to see a GUI release 1.0, but clearly this is something we wont manage in the next few months. This leave your first two options. There is one fundamental difference between gui classes and base classes. Most of the Foundation classes encapsulate a clear well defined concept that wont change over time, whereas Apple keeps on extending the AppKit classes to include more and more features. For that reason the approach to have a few dummy ivars will only work for a limited amount of time or for just a few classes. For the more flexible classes I would expect that the pointer to some separately allocated memory is the only option that is worth considering. Here we have different possibilities. For something like the NSClass hierarchy either each class could have its own extension pointer and in the end its own extra memory. Or we implement a basic mechanism for that once in NSClass and only require additional space in each subclass. That way we would only need on additional malloc/free call, on one per subclass. There are more details that need to be sorted out, but this is clearly the way to go. Cheers, Fred Gregory John Casamento wrote: > Adam/Fred, > > One of the things I think we need to do in order to address the ABI > compatibility issue is to adopt a strategy similar to what Apple has > done in it's headers. > > Currently there is a lot of space which is marked as "reserved" in > Apple's header files. This allows for future additions without > changing the memory layout of the class which is what leads to ABI > issues and subsequently the need for recompilation. This would allow > older versions of applications to continue to function with newer > versions of the core libraries even after a modification where some > of the "reserved" space has been consumed. The trick is to reserve > just the right amount of space so that you don't make your classes > needlessly big and so that you adequately anticipate the future > growth of some. > > Another potential solution to this problem, a bit different from the > one above and probably a little risky is to simply have a void > pointer in each class' ivar section and have it point to the > appropriate structure when initialized during runtime. This would > allow the ABI to be stable since the class' foot print would always > be the size of the void pointer. The structure could then be > changed to our hearts content without need to worry about ABI > compatibility issues at all. The drawback to this one is that it's a > major undertaking to implement it and, it's, potentially hazardous. > > The third option is to get gui to a point where it's ABI is actually > stable. Consider that base hasn't changed much for a long time. > This is because it's been at 1.0 for a very long time and because it > is truly stable. > > There are a myriad of things we need to focus on in gui at this point > before we can, rightfully, call it a 1.0 release. Printing is the > one thing that I think is most prominent on my mind regarding gui at > this point. Printing is incomplete. Last time I started up > TextEdit.app or Ink.app and typed and tried to print a page, it came > out blank. This could be a configuration issue, or it could be > something else, I don't know.. if it is, please tell me. :) > > Anyway... I'll come back later and we can discuss what gui 1.0 should > be. :) > > Later, GJC > > Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief > Maintainer > > - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: > Adam Fedor <[EMAIL PROTECTED]> Cc: Developer GNUstep > Sent: Tuesday, March 4, 2008 1:37:49 PM > Subject: Re: Next release > > Adam Fedor wrote: >> On Mar 3, 2008, at 1:40 PM, Riccardo wrote: >> >>> A newer stable release should be done indeed. Adam? >>> >> That's up to Gregory, et. al. Do we have any goals for the next >> stable release? gui 1.0? >> > > I am still a bit reluctant to use the version number 1.0. We would be > committing us to stay ABI compatible from then on and we are not > ready for that. Using the number 0.14.0 would be fine for me. > > (I already have a proposal for ABI stability, I just need time to > write it up and then find somebody to implement it :-) > > Fred > > > ___ Gnustep-dev mailing > list Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On 08.03.2008, at 00:33, Gregory John Casamento wrote: Currently there is a lot of space which is marked as "reserved" in Apple's header files. This allows for future additions without changing the memory layout of the class which is what leads to ABI issues and subsequently the need for recompilation. Didn't that change in Objective-C 2.0 / the 64bit ABI? I thought the fragile base class problem is no more? (due to ivar indirection). The trick is to reserve just the right amount of space so that you don't make your classes needlessly big Well, the instances would be big, not the classes :-) Another potential solution to this problem, a bit different from the one above and probably a little risky is to simply have a void pointer in each class' ivar section and have it point to the appropriate structure when initialized during runtime. I *guess* thats how its implemented in ObjC 2.0. The class probably doesn't contain the ivars directly, but just a pointer to the ivar block of the specific class. But I didn't check. Maybe someone else knows more. The third option is to get gui to a point where it's ABI is actually stable. Consider that base hasn't changed much for a long time. The ABI unfortunately *did* change a lot, I outlined that in detail several times, please check the archives. Stable ABI is not just ivar layout, but also stable method behaviour and constant public API (no public methods added!/changed, no classes added/changed, no methods moved to categories etc etc). Having a stable ABI might even imply preserving certain kinds of bugs :-) I can't say how stable the GUI ABI is, but the base ABI definitely is NOT stable at all (just say KVC ;-). And *please* remember that I don't refer to the stability of the code, but to the stability of the ABI only. The stability of the code is very nice, so if you don't have a problem with staying at trunk / last branch, everything is awesome-O :-) We do. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
BTW: sometimes people don't know what ABI compatibility implies in the real world. The basic idea is that if I have a library and a tool, I can replace 'library' with any ABI compatible library and the tool still works. Stuff like crasher bugs being fixed. Say, I have installed gnustep-base 0.13.0 SOGo 0.7.3 If gnustep-base 0.17.0 would be ABI compatible to 0.13.0, I could just replace it and SOGo 0.7.3 would still work. This is much harder than API (not ABI) compat with 0.7.3. The latter only requires that I can recompile 0.7.3 against the new API version (fragile baseclass is just a small part in this scenario). A simple (admittedly constructed) example: lets say gnustep-base 0.13.0 had: @interface NSObject ... - (BOOL)isNotEmpty; @end Well, and SOGo might have choosen to *override* that method using a category. Which is perfectly valid in ObjC: @interface NSObject(SOGo) - (BOOL)isNotEmpty; @end Now gnustep-base 0.17.0 might have said: well, isNotEmpty really does not belong to NSObject!, lets refactor it! and move it to a category: @interface NSObject(GSAdditions) - (BOOL)isNotEmpty; @end Hey! We just b0rked ABI compat :-) SOGo's implementation of - isNotEmpty won't get used anymore, even though it worked just fine before. Apple's frameworks are in fact ABI compatible this way (well they sometimes have bugs in that, but overall they have great ABI compatibility). ABI compat bascially means you are not allowed to touch the code except in *very* well defined ways. (eg Apple reserves the NS* namespace, so they are 'allowed' to add classes and still have ABI downwards compat). Greets, Helge ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
What ever numbering system you prefer :-) To me it is just the same and people will always find a reason to complain about it. For gui I would like to delay a new release for a few weeks. Gregory has done a load of changes which will need some testing. And one set of them (The changes for autoresize on NSView and subviews) surely is a work around for some kind of problem. I am still trying to figure out from the changes what the underlying problem might be. Most of the changes have been reverted, but the remaining on on NSSplitView leads to an inconsistency between objects loaded from a NIB file and ones created in code. This is not what we want, but Greg surely had a good reason for this change. If only he would tell us... I am also currently looking into a problem with NIB loading, which might even be related to Gregs issue. The NIB file for the SimpleWebKit Browser gives different results for the autoresizes subviews ivar on Cocoa and GNUstep. This code uses a binary NIB file devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib When converting this NIB file to XML (with a simple tool I have written that just uses to calls on NSPropertyList) I end up with an entry NSvFlags This looks completely wrong to me, but perhaps somebody with more understanding of keyed coding could explain this? After these two issues have been resolved a new release would be fine from my point of view. Fred PS: I will be away for the next ten days, so don't expect something quick. Adam Fedor wrote: > It's been a long time now (LTN) since our last release, perhaps we > should do a new one soon? Also, in an effort to please everyone > (ETPE), I was thinking we should separate the release numbering from the > SO version numbering, at least on the unstable branch as long as there > are no ABI changes. This should be really easy as we just need to define > > INTERFACE_VERSION > > in the top-level makefile. So > > Base/Gui unstable release: > Subminor release (1.19.X) - bug fixes or API changes > increase subminor version > interface version does not change > Minor release (1.X.0) - API changes and bug fixes > increase minor version > interface version does not change > Minor or Major release (1.X.0 or X.0.0) - ABI and API changes > increase version > increase interface version to match. > > Base/Gui stable release: > Subminor release (1.18.X) - bug fixes only > increase subminor version > interface version does not change > Minor release (1.X.0) - ABI, API changes and bug fixes > increase minor version > interface version changes to match > Minor or Major release (1.X.0 or X.0.0) - ABI and API changes > increase version > increase interface version to match. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
I agree that we should delay the release of gui since there have been a number of changes that have not been fully tested. While I'm sure that they are working I have tested them with a limited set of apps and would like to see a greater degree of testing done prior to an official release. The change to NSSplitView is based on the idea that the subviews of the splitview should always resize themselves since this appears to be the observed behavior on Cocoa. I need to do further testing on this, so I left it in the nib loading code for now. Regarding inconsistencies between loading from a nib and creating in code, I'm not sure that the assumption that they should always be the same is entirely valid. GC On 4/15/09, Fred Kiefer wrote: > What ever numbering system you prefer :-) > To me it is just the same and people will always find a reason to > complain about it. > > For gui I would like to delay a new release for a few weeks. Gregory has > done a load of changes which will need some testing. And one set of them > (The changes for autoresize on NSView and subviews) surely is a work > around for some kind of problem. I am still trying to figure out from > the changes what the underlying problem might be. Most of the changes > have been reverted, but the remaining on on NSSplitView leads to an > inconsistency between objects loaded from a NIB file and ones created in > code. This is not what we want, but Greg surely had a good reason for > this change. If only he would tell us... > > > I am also currently looking into a problem with NIB loading, which might > even be related to Gregs issue. The NIB file for the SimpleWebKit > Browser gives different results for the autoresizes subviews ivar on > Cocoa and GNUstep. This code uses a binary NIB file > devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib > > When converting this NIB file to XML (with a simple tool I have written > that just uses to calls on NSPropertyList) I end up with an entry > > NSvFlags > > > This looks completely wrong to me, but perhaps somebody with more > understanding of keyed coding could explain this? > > After these two issues have been resolved a new release would be fine > from my point of view. > > Fred > > PS: I will be away for the next ten days, so don't expect something quick. > > Adam Fedor wrote: >> It's been a long time now (LTN) since our last release, perhaps we >> should do a new one soon? Also, in an effort to please everyone >> (ETPE), I was thinking we should separate the release numbering from the >> SO version numbering, at least on the unstable branch as long as there >> are no ABI changes. This should be really easy as we just need to define >> >> INTERFACE_VERSION >> >> in the top-level makefile. So >> >> Base/Gui unstable release: >> Subminor release (1.19.X) - bug fixes or API changes >> increase subminor version >> interface version does not change >> Minor release (1.X.0) - API changes and bug fixes >> increase minor version >> interface version does not change >> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >> increase version >> increase interface version to match. >> >> Base/Gui stable release: >> Subminor release (1.18.X) - bug fixes only >> increase subminor version >> interface version does not change >> Minor release (1.X.0) - ABI, API changes and bug fixes >> increase minor version >> interface version changes to match >> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >> increase version >> increase interface version to match. > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
I think we waited now long enough to be sure there wont be any big surprises when we make a new release. There still are important open issues, but as far as I can see no regressions. I will be away for the next week, perhaps this is the perfect time for a release. When I come back I will have plenty of time for fixes. Cheers Fred Gregory Casamento wrote: > I agree that we should delay the release of gui since there have been > a number of changes that have not been fully tested. While I'm sure > that they are working I have tested them with a limited set of apps > and would like to see a greater degree of testing done prior to an > official release. > > The change to NSSplitView is based on the idea that the subviews of > the splitview should always resize themselves since this appears to be > the observed behavior on Cocoa. I need to do further testing on this, > so I left it in the nib loading code for now. > > Regarding inconsistencies between loading from a nib and creating in > code, I'm not sure that the assumption that they should always be the > same is entirely valid. > > GC > > On 4/15/09, Fred Kiefer wrote: >> What ever numbering system you prefer :-) >> To me it is just the same and people will always find a reason to >> complain about it. >> >> For gui I would like to delay a new release for a few weeks. Gregory has >> done a load of changes which will need some testing. And one set of them >> (The changes for autoresize on NSView and subviews) surely is a work >> around for some kind of problem. I am still trying to figure out from >> the changes what the underlying problem might be. Most of the changes >> have been reverted, but the remaining on on NSSplitView leads to an >> inconsistency between objects loaded from a NIB file and ones created in >> code. This is not what we want, but Greg surely had a good reason for >> this change. If only he would tell us... >> >> >> I am also currently looking into a problem with NIB loading, which might >> even be related to Gregs issue. The NIB file for the SimpleWebKit >> Browser gives different results for the autoresizes subviews ivar on >> Cocoa and GNUstep. This code uses a binary NIB file >> devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib >> >> When converting this NIB file to XML (with a simple tool I have written >> that just uses to calls on NSPropertyList) I end up with an entry >> >> NSvFlags >> >> >> This looks completely wrong to me, but perhaps somebody with more >> understanding of keyed coding could explain this? >> >> After these two issues have been resolved a new release would be fine >> from my point of view. >> >> Fred >> >> PS: I will be away for the next ten days, so don't expect something quick. >> >> Adam Fedor wrote: >>> It's been a long time now (LTN) since our last release, perhaps we >>> should do a new one soon? Also, in an effort to please everyone >>> (ETPE), I was thinking we should separate the release numbering from the >>> SO version numbering, at least on the unstable branch as long as there >>> are no ABI changes. This should be really easy as we just need to define >>> >>> INTERFACE_VERSION >>> >>> in the top-level makefile. So >>> >>> Base/Gui unstable release: >>> Subminor release (1.19.X) - bug fixes or API changes >>> increase subminor version >>> interface version does not change >>> Minor release (1.X.0) - API changes and bug fixes >>> increase minor version >>> interface version does not change >>> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >>> increase version >>> increase interface version to match. >>> >>> Base/Gui stable release: >>> Subminor release (1.18.X) - bug fixes only >>> increase subminor version >>> interface version does not change >>> Minor release (1.X.0) - ABI, API changes and bug fixes >>> increase minor version >>> interface version changes to match >>> Minor or Major release (1.X.0 or X.0.0) - ABI and API changes >>> increase version >>> increase interface version to match. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Fred, I agree. I think we're in good shape to do a release. We can discuss any issues when you get back. Thanks, GC On Wednesday, May 6, 2009, Fred Kiefer wrote: > I think we waited now long enough to be sure there wont be any big > surprises when we make a new release. > There still are important open issues, but as far as I can see no > regressions. I will be away for the next week, perhaps this is the > perfect time for a release. When I come back I will have plenty of time > for fixes. > > Cheers > Fred > > Gregory Casamento wrote: >> I agree that we should delay the release of gui since there have been >> a number of changes that have not been fully tested. While I'm sure >> that they are working I have tested them with a limited set of apps >> and would like to see a greater degree of testing done prior to an >> official release. >> >> The change to NSSplitView is based on the idea that the subviews of >> the splitview should always resize themselves since this appears to be >> the observed behavior on Cocoa. I need to do further testing on this, >> so I left it in the nib loading code for now. >> >> Regarding inconsistencies between loading from a nib and creating in >> code, I'm not sure that the assumption that they should always be the >> same is entirely valid. >> >> GC >> >> On 4/15/09, Fred Kiefer wrote: >>> What ever numbering system you prefer :-) >>> To me it is just the same and people will always find a reason to >>> complain about it. >>> >>> For gui I would like to delay a new release for a few weeks. Gregory has >>> done a load of changes which will need some testing. And one set of them >>> (The changes for autoresize on NSView and subviews) surely is a work >>> around for some kind of problem. I am still trying to figure out from >>> the changes what the underlying problem might be. Most of the changes >>> have been reverted, but the remaining on on NSSplitView leads to an >>> inconsistency between objects loaded from a NIB file and ones created in >>> code. This is not what we want, but Greg surely had a good reason for >>> this change. If only he would tell us... >>> >>> >>> I am also currently looking into a problem with NIB loading, which might >>> even be related to Gregs issue. The NIB file for the SimpleWebKit >>> Browser gives different results for the autoresizes subviews ivar on >>> Cocoa and GNUstep. This code uses a binary NIB file >>> devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/MyDocument.nib/keyedobjects.nib >>> >>> When converting this NIB file to XML (with a simple tool I have written >>> that just uses to calls on NSPropertyList) I end up with an entry >>> >>> NSvFlags >>> >>> >>> This looks completely wrong to me, but perhaps somebody with more >>> understanding of keyed coding could explain this? >>> >>> After these two issues have been resolved a new release would be fine >>> from my point of view. >>> >>> Fred >>> >>> PS: I will be away for the next ten days, so don't expect something quick. >>> >>> Adam Fedor wrote: It's been a long time now (LTN) since our last release, perhaps we should do a new one soon? Also, in an effort to please everyone (ETPE), I was thinking we should separate the release numbering from the SO version numbering, at least on the unstable branch as long as there are no ABI changes. This should be really easy as we just need to define INTERFACE_VERSION in the top-level makefile. So Base/Gui unstable release: Subminor release (1.19.X) - bug fixes or API changes increase subminor version interface version does not change Minor release (1.X.0) - API changes and bug fixes increase minor version interface version does not change Minor or Major release (1.X.0 or X.0.0) - ABI and API changes increase version increase interface version to match. Base/Gui stable release: Subminor release (1.18.X) - bug fixes only increase subminor version interface version does not change Minor release (1.X.0) - ABI, API changes and bug fixes increase minor version interface version changes to match Minor or Major release (1.X.0 or X.0.0) - ABI and API changes increase version > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
I can make a release of the core libraries in the next day or two if that's OK. This was my plan: make 2.0.9 base 1.19.1 gui 0.17.0 back 0.17.0 On May 6, 2009, at 11:54 AM, Gregory Casamento wrote: Fred, I agree. I think we're in good shape to do a release. We can discuss any issues when you get back. Thanks, GC On Wednesday, May 6, 2009, Fred Kiefer wrote: I think we waited now long enough to be sure there wont be any big surprises when we make a new release. There still are important open issues, but as far as I can see no regressions. I will be away for the next week, perhaps this is the perfect time for a release. When I come back I will have plenty of time for fixes. Cheers Fred Gregory Casamento wrote: I agree that we should delay the release of gui since there have been a number of changes that have not been fully tested. While I'm sure that they are working I have tested them with a limited set of apps and would like to see a greater degree of testing done prior to an official release. The change to NSSplitView is based on the idea that the subviews of the splitview should always resize themselves since this appears to be the observed behavior on Cocoa. I need to do further testing on this, so I left it in the nib loading code for now. Regarding inconsistencies between loading from a nib and creating in code, I'm not sure that the assumption that they should always be the same is entirely valid. GC On 4/15/09, Fred Kiefer wrote: What ever numbering system you prefer :-) To me it is just the same and people will always find a reason to complain about it. For gui I would like to delay a new release for a few weeks. Gregory has done a load of changes which will need some testing. And one set of them (The changes for autoresize on NSView and subviews) surely is a work around for some kind of problem. I am still trying to figure out from the changes what the underlying problem might be. Most of the changes have been reverted, but the remaining on on NSSplitView leads to an inconsistency between objects loaded from a NIB file and ones created in code. This is not what we want, but Greg surely had a good reason for this change. If only he would tell us... I am also currently looking into a problem with NIB loading, which might even be related to Gregs issue. The NIB file for the SimpleWebKit Browser gives different results for the autoresizes subviews ivar on Cocoa and GNUstep. This code uses a binary NIB file devmodules/dev-libs/simplewebkit/SWKBrowser/English.lproj/ MyDocument.nib/keyedobjects.nib When converting this NIB file to XML (with a simple tool I have written that just uses to calls on NSPropertyList) I end up with an entry NSvFlags This looks completely wrong to me, but perhaps somebody with more understanding of keyed coding could explain this? After these two issues have been resolved a new release would be fine from my point of view. Fred PS: I will be away for the next ten days, so don't expect something quick. Adam Fedor wrote: It's been a long time now (LTN) since our last release, perhaps we should do a new one soon? Also, in an effort to please everyone (ETPE), I was thinking we should separate the release numbering from the SO version numbering, at least on the unstable branch as long as there are no ABI changes. This should be really easy as we just need to define INTERFACE_VERSION in the top-level makefile. So Base/Gui unstable release: Subminor release (1.19.X) - bug fixes or API changes increase subminor version interface version does not change Minor release (1.X.0) - API changes and bug fixes increase minor version interface version does not change Minor or Major release (1.X.0 or X.0.0) - ABI and API changes increase version increase interface version to match. Base/Gui stable release: Subminor release (1.18.X) - bug fixes only increase subminor version interface version does not change Minor release (1.X.0) - ABI, API changes and bug fixes increase minor version interface version changes to match Minor or Major release (1.X.0 or X.0.0) - ABI and API changes increase version -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On May 8, 2009, at 12:04 PM, Nicola Pero wrote: On 7 May 2009, at 15:26, Adam Fedor wrote: I can make a release of the core libraries in the next day or two if that's OK. This was my plan: make 2.0.9 I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9). The idea being that 2.0.x does not support parallel building (make - j 2), while 2.2.x does support it. :-) OK, fine. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On 7 May 2009, at 15:26, Adam Fedor wrote: I can make a release of the core libraries in the next day or two if that's OK. This was my plan: make 2.0.9 I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9). The idea being that 2.0.x does not support parallel building (make -j 2), while 2.2.x does support it. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release?
On Monday, December 9, 2013 23:00 CET, Fred Kiefer wrote: > I would like to suggest to have a shared release of the GNUstep core > components before the end of this year. This is great, and I'm all for it. > There was a base release a few months ago, but the last gui/back release > was more than six months ago. And right after that release I fixed a bug > in gui that will show up with all newer Linux systems. > > It would be great, if many different people could test the SVN code on a > lot of different systems. At the moment I am myself testing the current > GNUstep code on OpenSuse 13.1. There the copy/paste mechanism seems to > be broken. When calling copy from the menu I get the following stack dump: > I have a problem with GNUstep make. With the ImpersonatorToolKit, I have a Tool with additional Resource files that need to get installed. So I have them in the Resources subdirectory, and in GNUmakefile I have set: ImpersonatorToolKit_HAS_RESOURCE_BUNDLE=yes then make && make install works well and as expected, but trying to do: make clean completely wipes the Resources directory from the disk. This is only annoying when you have the stuff in SVN or elsewhere, but may wipe important stuff before you have it in a RCS ;) The patch below fixes the problem for me, only deleting the subdirectory that gets created when calling make . Before I came up with the patch as it is currently below, I stumbled about the GNUSTEP_SHARED_BUNDLE_RESOURCE_PATH variable that gets filled in Instance/tool.make, but trying to use that variable, its empty at the make clean stage, so didn't work. Is that patch the right approach to the problem? If so, I'd like to go on and commit it, otherwise I'm open for other suggestions. cheers, Sebastian $OpenBSD$ --- Master/tool.make.orig Wed Dec 11 07:24:02 2013 +++ Master/tool.makeWed Dec 11 07:25:46 2013 @@ -41,7 +41,7 @@ $(GNUSTEP_BUILD_DIR)/Resources: # On distclean, we want to efficiently wipe out the Resources/ # directory. internal-clean:: - rm -rf $(GNUSTEP_BUILD_DIR)/Resources + rm -rf $(MAYBE_GNUSTEP_BUILD_DIR_RESOURCES)/$(TOOL_NAME) else MAYBE_GNUSTEP_BUILD_DIR_RESOURCES = endif ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Le 16 mars 05, à 11:03, Stefan Urbanek a écrit : Hi, What are the plans for the next GNUstep -bas and -gui releases? Is it possible to make minor releases more often and to publish plans/todos for next major and minor releases? Hi Stefan, It's a welcome addition to wiki. You can move tasks which are in Tasks tracker first to start in my opinion. I read you previous mail on this subject and I have hoped to reply to it, but frankly I haven't been found the time to put on wiki what I would like to do or to be done on my side for -gui… (First I have -gui patches to clean and to submit :-/) Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 16, 2005, at 3:03 AM, Stefan Urbanek wrote: Hi, What are the plans for the next GNUstep -bas and -gui releases? Is it possible to make minor releases more often and to publish plans/todos for next major and minor releases? Moreover, can people who make releases describe the whole process on the new wiki so others delegated developers can make the releases when official release manager can not? My plan so far: binary compatible releases (by the end of March) base 1.10.2 (based on CVS from Feb 22 2005) gui 0.9.5 back 0.9.5 Actually, I'm ahead of things so I could make these releases even sooner if there is general interest. binary incompatible release (a few weeks or month later): base 1.11.0 gui 0.10.0 back 0.10.0 Really, the hard part is not 'making' the release. That's quite easy and almost fun. The part I really want help with is having people who know each library well to act as library managers - make up a list of release criteria and tell me when a good time to make a release is. GNUstep is to big and too much work for me to do this all by myself. Steps for releasing the GNUstep core libraries (as well as others) 1. Make sure news.texi and ReleaseNotes.gsdoc files are updated 2. Update the 'Version' file with the new version 3. Update the documentation and release notes in the main directory: cd Documentation make clean; make; make regenerate 4. Commit the changed files (add a line in the ChangeLog, like '* Version 1.10.0' as well). 5. Tag the release make cvs-tag 6. Make a source distribution make cvs-dist 7. Administrative stuff (scripts that I use to make this easier are in brackets): Make RPMS or whatever [gstep-distribute] Sign the packages [gstep-sign] Upload packages to ftp.gnustep.org [gstep-update, gstep-upload] Install the documentation and copy it to the web repository [update_documentation] Update the index.html and resources/downloads.php pages with the news. Commit the web repository. Make an announcement on info-gnustep@gnu.org, etc gstep-distribute, gstep-update: must be run as root/sudo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Citát Adam Fedor <[EMAIL PROTECTED]>: > > On Mar 16, 2005, at 3:03 AM, Stefan Urbanek wrote: > > > Hi, > > > > What are the plans for the next GNUstep -bas and -gui releases? > > > > Is it possible to make minor releases more often and to publish > > plans/todos for > > next major and minor releases? > > > > Moreover, can people who make releases describe the whole process on > > the new > > wiki so others delegated developers can make the releases when > > official release > > manager can not? > > > I've put the instructions here: http://mediawiki.gnustep.org/index.php/GNUstep_release_procedure Wehre one can find the scripts you are mentioning there? > My plan so far: > > binary compatible releases (by the end of March) > base 1.10.2 (based on CVS from Feb 22 2005) > gui 0.9.5 > back 0.9.5 > Can this be more often? Last minor gui release dates to september or october last year. Most of GNUstep based projects requre "fresh GNUstep CVS checkout". That requirement should be totaly removed. > Actually, I'm ahead of things so I could make these releases even > sooner if there is general interest. > See argument above. > binary incompatible release (a few weeks or month later): > base 1.11.0 > gui 0.10.0 > back 0.10.0 > > Really, the hard part is not 'making' the release. That's quite easy > and almost fun. The part I really want help with is having people who > know each library well to act as library managers - make up a list of > release criteria and tell me when a good time to make a release is. > GNUstep is to big and too much work for me to do this all by myself. > What about explicitly assigning and publishing a core developer(s) to each GNUstep package? The package development leader should: - publish TODO list and goals for the package - publish plans for the next release (can be discussed with others) - approve releases The last one means, that the package development leader do not have to do the release if he does not have time. He just approves that anyone else can make the release. Releases can do even novice GNUstep users if they have instructions and approval. If nothing else, they can at least learn the sctructure of the GNUstep by this. In addition, ca we make releases even there were no significant changes in the library, only small bugfices? Those releases can keep GNUstep users attentive and they will at least have the impression, that something is happening. "Hey, we care about you, here is a new releases with fixes of the problem you were having, you do not need to use that hack anymore.". Problem is, that we all are living too much in the CVS GNUstep world and see constant changes. Outside world does not see the changes. Here is the Roadmap page: http://mediawiki.gnustep.org/index.php/Roadmap Perhaps we should have "Roadmap - package_name" pages if the first one will be too long. Thoughts? Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 17, 2005, at 6:50 AM, Stefan Urbanek wrote: Citát Adam Fedor <[EMAIL PROTECTED]>: Really, the hard part is not 'making' the release. That's quite easy and almost fun. The part I really want help with is having people who know each library well to act as library managers - make up a list of release criteria and tell me when a good time to make a release is. GNUstep is to big and too much work for me to do this all by myself. What about explicitly assigning and publishing a core developer(s) to each GNUstep package? The package development leader should: - publish TODO list and goals for the package - publish plans for the next release (can be discussed with others) - approve releases It's probably not necessary to burden "core developers" with these tasks if others are willing to help out. There are some people who do a lot of coding in base and gui and tend to give advice on patches and the like. If any of them want to serve as release manager for base, gui, or back then that's great. But it if not, that's great too, as long as they can coordinate with someone else who handles the mechanics of managing bug reports, doing stabilization branches, etc.. In this model, the release manager gets advice on technical issues and good time points for releases from the technical folks, who go on concentrating on coding and reviewing patches. Communications are important -- this would only work if there were specific designated people the release manager could contact with questions and who are committed to helping them with decisions. If this could be set up, then it might also be possible to consider some kind of regularized release schedule, which might help people delivering apps, packaging for distributions, etc.. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Mar 17, 2005, at 8:13 AM, Adrian Robert wrote: It's probably not necessary to burden "core developers" with these tasks if others are willing to help out. There are some people who do a lot of coding in base and gui and tend to give advice on patches and the like. If any of them want to serve as release manager for base, gui, or back then that's great. But it if not, that's great too, as long as they can coordinate with someone else who handles the mechanics of managing bug reports, doing stabilization branches, etc.. In this model, the release manager gets advice on technical issues and good time points for releases from the technical folks, who go on concentrating on coding and reviewing patches. Communications are important -- this would only work if there were specific designated people the release manager could contact with questions and who are committed to helping them with decisions. If this could be set up, then it might also be possible to consider some kind of regularized release schedule, which might help people delivering apps, packaging for distributions, etc.. Sounds like a good idea. We could use someone who is only moderately familiar with the libraries to collect suggestions and draw up a release plan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On 23 Aug 2006, at 13:44, Adam Fedor wrote: Should I increase the subversion/SONAME of base? It's been a long time and lots of stuff has been added. Certainly. I had hoped to be able to do more (socks and ssh support for NSStream, completion of the new apple URL handling classes etc), but the new APIs are in place, so incrementing the library version is pretty essential for these. We should freeze the code for core as well, probably Friday, so we have a chance to make a release. I'm away from home next week ... so I won't be able to do anything on the code then anyway. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release/Binary incompatibilities
On Jun 6, 2005, at 8:43 AM, Adam Fedor wrote: Lets set the cut-off date for adding binary incompatible changes as June 14. I'll try to get a release out by June 28 then. Note - my definition of binary incompatible is a change that does not allow the OS to resolve a symbol at runtime or cause memory/ivar incompatibilities when starting an application or tool that was compiled with the previous library. Behavior changes don't count as those can be documented, and presumably a developer can update their app to match with the new library if necessary. I've pushed back the date for Binary incomptible changes to June 27, so the release will be about two weeks later. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gnustep-make problem with tools and resource bundles Re: Next release?
Ping! On Thursday, December 12, 2013 07:23 CET, "Sebastian Reitenbach" wrote: > > On Monday, December 9, 2013 23:00 CET, Fred Kiefer wrote: > > > I would like to suggest to have a shared release of the GNUstep core > > components before the end of this year. > > This is great, and I'm all for it. > > > There was a base release a few months ago, but the last gui/back release > > was more than six months ago. And right after that release I fixed a bug > > in gui that will show up with all newer Linux systems. > > > > It would be great, if many different people could test the SVN code on a > > lot of different systems. At the moment I am myself testing the current > > GNUstep code on OpenSuse 13.1. There the copy/paste mechanism seems to > > be broken. When calling copy from the menu I get the following stack dump: > > > > > I have a problem with GNUstep make. With the ImpersonatorToolKit, I have > a Tool with additional Resource files that need to get installed. So I have > them in the Resources subdirectory, and in GNUmakefile I have set: > > ImpersonatorToolKit_HAS_RESOURCE_BUNDLE=yes > > then > make && make install > works well and as expected, but trying to do: > make clean > > completely wipes the Resources directory from the disk. This is only annoying > when you have the stuff in SVN or elsewhere, but may wipe important stuff > before > you have it in a RCS ;) > > The patch below fixes the problem for me, only deleting the subdirectory > that gets created when calling make . > Before I came up with the patch as it is currently below, I stumbled about > the GNUSTEP_SHARED_BUNDLE_RESOURCE_PATH variable that gets > filled in Instance/tool.make, but trying to use that variable, its empty at > the make clean stage, so didn't work. > Is that patch the right approach to the problem? If so, I'd like to go on > and commit it, otherwise I'm open for other suggestions. > > > > cheers, > Sebastian > > > > $OpenBSD$ > --- Master/tool.make.orig Wed Dec 11 07:24:02 2013 > +++ Master/tool.make Wed Dec 11 07:25:46 2013 > @@ -41,7 +41,7 @@ $(GNUSTEP_BUILD_DIR)/Resources: > # On distclean, we want to efficiently wipe out the Resources/ > # directory. > internal-clean:: > - rm -rf $(GNUSTEP_BUILD_DIR)/Resources > + rm -rf $(MAYBE_GNUSTEP_BUILD_DIR_RESOURCES)/$(TOOL_NAME) > else > MAYBE_GNUSTEP_BUILD_DIR_RESOURCES = > endif > > > > ___ > 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: gnustep-make problem with tools and resource bundles Re: Next release?
Sorry for not replying earlier. I am no expert on GNUstep make, but your change seems valid to me. The worst that should result from it is a left over Resource folder in the build directory. You could limit your change to the case where GNUSTEP_BUILD_DIR is equal to "." in all other cases the old code seems fine. But then this condition may be hard to check when different notations for the same directory are possible. Fred On 22.12.2013 08:43, Sebastian Reitenbach wrote: > Ping! > > On Thursday, December 12, 2013 07:23 CET, "Sebastian Reitenbach" > wrote: >> I have a problem with GNUstep make. With the ImpersonatorToolKit, I have >> a Tool with additional Resource files that need to get installed. So I have >> them in the Resources subdirectory, and in GNUmakefile I have set: >> >> ImpersonatorToolKit_HAS_RESOURCE_BUNDLE=yes >> >> then >> make && make install >> works well and as expected, but trying to do: >> make clean >> >> completely wipes the Resources directory from the disk. This is only annoying >> when you have the stuff in SVN or elsewhere, but may wipe important stuff >> before >> you have it in a RCS ;) >> >> The patch below fixes the problem for me, only deleting the subdirectory >> that gets created when calling make . >> Before I came up with the patch as it is currently below, I stumbled about >> the GNUSTEP_SHARED_BUNDLE_RESOURCE_PATH variable that gets >> filled in Instance/tool.make, but trying to use that variable, its empty at >> the make clean stage, so didn't work. >> Is that patch the right approach to the problem? If so, I'd like to go on >> and commit it, otherwise I'm open for other suggestions. >> >> >> >> cheers, >> Sebastian >> >> >> >> $OpenBSD$ >> --- Master/tool.make.origWed Dec 11 07:24:02 2013 >> +++ Master/tool.make Wed Dec 11 07:25:46 2013 >> @@ -41,7 +41,7 @@ $(GNUSTEP_BUILD_DIR)/Resources: >> # On distclean, we want to efficiently wipe out the Resources/ >> # directory. >> internal-clean:: >> -rm -rf $(GNUSTEP_BUILD_DIR)/Resources >> +rm -rf $(MAYBE_GNUSTEP_BUILD_DIR_RESOURCES)/$(TOOL_NAME) >> else >> MAYBE_GNUSTEP_BUILD_DIR_RESOURCES = >> endif ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
