Re: Next GNUstep release?
As I remember it, we agreed on GCC 4.0 and later. On Tuesday, November 8, 2011, Riccardo Mottola wrote: > Hi, > > I think it is a good idea to release gui&back. Things are piling up and diverging from base, so they are indeed needed. I am feeling some itches lately though, but they can surely be solved. > > The new cairo surface usage is not prefect, but it is quite good, if some of the performance and flicker issues can be addressed, i should get definitively released. > > gcc 4.0? that's a bit too much. We agreed to drop 2.95 for the need of better c99 support and macros, but not 3.x series AFAIR. > > Riccardo > > Fred Kiefer wrote: >> >> For over a month I have been suggesting a new release of all GNUstep code components (perhaps including Gorm as well), but got no reply at all. Many of us have been pretty busy fixing the bugs Julian reported and there is still plenty to do in this area. Anyway I would like to start a discussion about this subject. >> >> After the last base release we did not make a gui/back release although some of the changes in base wont work with an old version of gui. This means anybody wanting to use GNUstep with a graphical user interface either has to use a very old release of all components or use SVN. The later is especially bad for distributions as they will have to ship an unclear state of the code. >> >> I will be away the first two weeks of December and would either like to see a release before that or after, but wont be available for last minute bug fixes during that period. >> There are a few changes to gui/back which I would like to see done before the release. One is the conversion of the Ghostscript and the ImageMagick bitmap implementations into filter services. The other is the integration of the real cairo font interface (instead of the currently used toy fonts) as prototyped in Opal. Is there anything important I did forget? >> >> It would be great if everybody could start to test its favourite application to find out whether any of the recent changes introduced new issues. What are the plans for GNUstep make and base? I think there have been enough changes in base that warrant a new release and gui requires some of these changes. For make there are a few open bug reports, maybe some of them could be fixed for the release? >> >> Please remember that this will be the first GNUstep release that requires gcc >= 4.0. We decided so at the last base release and gui requires a current base version. >> >> ___ >> 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 > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, I think it is a good idea to release gui&back. Things are piling up and diverging from base, so they are indeed needed. I am feeling some itches lately though, but they can surely be solved. The new cairo surface usage is not prefect, but it is quite good, if some of the performance and flicker issues can be addressed, i should get definitively released. gcc 4.0? that's a bit too much. We agreed to drop 2.95 for the need of better c99 support and macros, but not 3.x series AFAIR. Riccardo Fred Kiefer wrote: For over a month I have been suggesting a new release of all GNUstep code components (perhaps including Gorm as well), but got no reply at all. Many of us have been pretty busy fixing the bugs Julian reported and there is still plenty to do in this area. Anyway I would like to start a discussion about this subject. After the last base release we did not make a gui/back release although some of the changes in base wont work with an old version of gui. This means anybody wanting to use GNUstep with a graphical user interface either has to use a very old release of all components or use SVN. The later is especially bad for distributions as they will have to ship an unclear state of the code. I will be away the first two weeks of December and would either like to see a release before that or after, but wont be available for last minute bug fixes during that period. There are a few changes to gui/back which I would like to see done before the release. One is the conversion of the Ghostscript and the ImageMagick bitmap implementations into filter services. The other is the integration of the real cairo font interface (instead of the currently used toy fonts) as prototyped in Opal. Is there anything important I did forget? It would be great if everybody could start to test its favourite application to find out whether any of the recent changes introduced new issues. What are the plans for GNUstep make and base? I think there have been enough changes in base that warrant a new release and gui requires some of these changes. For make there are a few open bug reports, maybe some of them could be fixed for the release? Please remember that this will be the first GNUstep release that requires gcc >= 4.0. We decided so at the last base release and gui requires a current base version. ___ 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
Next GNUstep release?
For over a month I have been suggesting a new release of all GNUstep code components (perhaps including Gorm as well), but got no reply at all. Many of us have been pretty busy fixing the bugs Julian reported and there is still plenty to do in this area. Anyway I would like to start a discussion about this subject. After the last base release we did not make a gui/back release although some of the changes in base wont work with an old version of gui. This means anybody wanting to use GNUstep with a graphical user interface either has to use a very old release of all components or use SVN. The later is especially bad for distributions as they will have to ship an unclear state of the code. I will be away the first two weeks of December and would either like to see a release before that or after, but wont be available for last minute bug fixes during that period. There are a few changes to gui/back which I would like to see done before the release. One is the conversion of the Ghostscript and the ImageMagick bitmap implementations into filter services. The other is the integration of the real cairo font interface (instead of the currently used toy fonts) as prototyped in Opal. Is there anything important I did forget? It would be great if everybody could start to test its favourite application to find out whether any of the recent changes introduced new issues. What are the plans for GNUstep make and base? I think there have been enough changes in base that warrant a new release and gui requires some of these changes. For make there are a few open bug reports, maybe some of them could be fixed for the release? Please remember that this will be the first GNUstep release that requires gcc >= 4.0. We decided so at the last base release and gui requires a current base version. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Hi Eric, I'm unable to build GNUstep due to no fault of your own: compiling gcc46 fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. Apparently gcc46 uses its own linker to link this library. For now, I am giving up. Can some older GCC be used if I am not interested in objc2.0 niceties? On Tue, Nov 8, 2011 at 20:04, Eric Wasylishen wrote: > Ok, great! > > Here are a few more notes: > > - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. > Using the fhs layout with macports will not work, because gnustep-make adds > the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with > the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will > mess up macports (basically, tools which link to apple versions of > libraries will pick up the macports versions in /opt/local/lib and break.) > > - Many of the application ports work now (e.g., gorm, systempreferences). > > - gnustep-back is currently set to xlib. When I use cairo, opening an > open/save panel crashes X11.app. Also tried the latest XQuartz: same > problem. > > - For anyone with OS X 10.7, my ports won't work until this bug is fixed: > https://trac.macports.org/ticket/31171 (building gcc46 on osx lion > fails). :-( > > - One improvement that could be made in the future is to use the system > compiler rather than the macports gcc46. For this we would need a portfile > which builds one of GNUstep's libobjc's, and make sure that the apple > compiler doesn't try to include headers for apple's libobjc. > > Regards > Eric > > On 2011-11-07, at 10:52 AM, Ivan Vučica wrote: > > Hi Eric, > > I've cloned the repo, and will be trying it out soon on my Snow Leopard > machine. If I forget to keep you posted, please poke me. > > On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen wrote: > >> Hi, >> >> I started a new set of macports ports. If you want to try it you can >> check out a copy of the git repository here: >> https://github.com/ericwa/gnustep-macports-fixes and then set up that >> directory as a local portfile repository (see >> http://guide.macports.org/#development.local-repositories). >> > > -- > Ivan Vučica - i...@vucica.net > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Am 08.11.2011 um 20:04 schrieb Eric Wasylishen: > Ok, great! > > Here are a few more notes: > > - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. > Using the fhs layout with macports will not work, because gnustep-make adds > the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with > the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will > mess up macports (basically, tools which link to apple versions of libraries > will pick up the macports versions in /opt/local/lib and break.) > > - Many of the application ports work now (e.g., gorm, systempreferences). > > - gnustep-back is currently set to xlib. When I use cairo, opening an > open/save panel crashes X11.app. Also tried the latest XQuartz: same problem. > > - For anyone with OS X 10.7, my ports won't work until this bug is fixed: > https://trac.macports.org/ticket/31171 (building gcc46 on osx lion fails). :-( > > - One improvement that could be made in the future is to use the system > compiler rather than the macports gcc46. For this we would need a portfile > which builds one of GNUstep's libobjc's, and make sure that the apple > compiler doesn't try to include headers for apple's libobjc. > > Regards > Eric This is great! Thanks for your effort. Btw. are those ports going to be at the macports repository? Thanks, Lars___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
Ok, great! Here are a few more notes: - It installs using the GNUstep filesystem layout in /opt/local/GNUstep. Using the fhs layout with macports will not work, because gnustep-make adds the gnustep library path to DYLD_LIBRARY_PATH, which is /opt/local/lib with the fhs layout, and if you add /opt/local/lib to DYLD_LIBRARY_PATH it will mess up macports (basically, tools which link to apple versions of libraries will pick up the macports versions in /opt/local/lib and break.) - Many of the application ports work now (e.g., gorm, systempreferences). - gnustep-back is currently set to xlib. When I use cairo, opening an open/save panel crashes X11.app. Also tried the latest XQuartz: same problem. - For anyone with OS X 10.7, my ports won't work until this bug is fixed: https://trac.macports.org/ticket/31171 (building gcc46 on osx lion fails). :-( - One improvement that could be made in the future is to use the system compiler rather than the macports gcc46. For this we would need a portfile which builds one of GNUstep's libobjc's, and make sure that the apple compiler doesn't try to include headers for apple's libobjc. Regards Eric On 2011-11-07, at 10:52 AM, Ivan Vučica wrote: > Hi Eric, > > I've cloned the repo, and will be trying it out soon on my Snow Leopard > machine. If I forget to keep you posted, please poke me. > > On Mon, Oct 31, 2011 at 19:53, Eric Wasylishen wrote: > Hi, > > I started a new set of macports ports. If you want to try it you can check > out a copy of the git repository here: > https://github.com/ericwa/gnustep-macports-fixes and then set up that > directory as a local portfile repository (see > http://guide.macports.org/#development.local-repositories). > > -- > Ivan Vučica - i...@vucica.net > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
