Removing all remaining distinction between shared, debug, profile and static libs/executables
Adam has removed the '_d' library name suffix for debug libraries ... a very welcome change which will make everything simpler and less liable to break :-) I think having done this, we lost the ability to have debug and non-debug libs at the same time, so we can simplify everything a lot ... without losing much more, since we have already done the big sacrifice ;-) So as a start I removed the '_p' library name suffix for profile libraries from gnustep-make too. But at this point, I'd like to complete the changes and take advantage of the corresponding simplifications ... I'd like to: 1. remove the difference between shared_obj, shared_debug_obj, static_profile_obj, etc. too. Just use './obj' for everything (this is kind of a no-brainer, now that there is no longer any difference in the installed libraries, can't see any reason to keep a difference while building!). Another advantage is we no longer need a symlink here :-) 2. remove the '_s' library name suffix for static libraries too (then we can get rid of which_lib.c entirely!) 3. rename Gorm.debug to Gorm.app, and other similar extension dropping any distinction between debug/non-debug executables/apps everywhere. Since libs are no longer differentiated, there is not that much point in keeping executables/apps different anyway. If we do those, then we can drop 'which_lib.c'! ... which means ... faster compiles, easier logic inside gnustep-make, no longer any need to build any C tool/program to run gnustep-make. :-) We can also simplify openapp and a lot of other scripts and supporting stuff quite a lot! :-) The only really interesting feature that we might lose seems to be the ability to have shared and static libraries on the same system with different names, so you can link to the static ones or to the shared ones depending on the command-line flag. At the moment our build system will link against the static libs if static=yes is passed on the command line, and also replace missing static libs with the corresponding shared ones. Unfortunately I'm not that sure this is a feature ;-) ... I mean if you want to do a static build, you probably don't want any shared lib to be used at all! :-) So I would be for just propagating static=yes into a '-static' flag to GCC (or whatever it is) that causes GCC to avoid shared libs and only use static ones. Also, obviously, use .so for shared and .a for static builds - we don't need to also add _s to the name. Eg, at the moment we use libgnustep-base_s.a libgnustep-base.so We would just switch to libgnustep-base.a libgnustep-base.so without much loss ... Presumably we then use the local library suffix for static/shared libs and here you go, you have libsomething.a and libsomething.so and if you use static=yes that generates -static to GCC and libsomething.a gets linked ... Anyway, if anyone has any comments before I do all this simplification, please let me know :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Thu, 2006-09-07 at 18:47 +0200, Nicola Pero wrote: > Adam has removed the '_d' library name suffix for debug libraries ... a > very welcome > change which will make everything simpler and less liable to break :-) > > I think having done this, we lost the ability to have debug and non-debug > libs at the > same time, so we can simplify everything a lot ... without losing much > more, since we > have already done the big sacrifice ;-) GDB can read debug info from a separate file, so it's quite possible to split the libraries, leaving a stripped version, and a file of the stripped info. PLD ships their binaries this way, a foo package and foo-debuginfo package. Works nicely, can download the corresponsing debuginfo if it's needed. Aria signature.asc Description: This is a digitally signed message part ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Sep 7, 2006, at 12:47 PM, Nicola Pero wrote: 1. remove the difference between shared_obj, shared_debug_obj, static_profile_obj, etc. too. Just use './obj' for everything (this is kind of a no-brainer, now that there is no longer any difference in the installed libraries, can't see any reason to keep a difference while building!). Another advantage is we no longer need a symlink here :-) This is probably best for simplification as you say but it will impose a cost to switching back and forth between, e.g., profiled and non-profiled versions. With the final library names merged you can still switch between them by doing a new "make install" (which will not require any compilation once you've built both), but merging these build directories means a full recompilation is needed to make the switch. Correct me if I'm missing something. Maybe it's not a big deal since one can do a manual work-around. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
I remember all the problem the which_lib tool did cause me, when trying to cross compile GNUstep. When it is finally gone, I may give cross compilation another go. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Sep 7, 2006, at 19:11, Adrian Robert wrote: This is probably best for simplification as you say but it will impose a cost to switching back and forth between, e.g., profiled and non-profiled versions. Do you actually use profiling with gprof? I've always used KCachegrind in the last few years instead. So IMHO its superflous anyway. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Sep 7, 2006, at 2:00 PM, Helge Hess wrote: On Sep 7, 2006, at 19:11, Adrian Robert wrote: This is probably best for simplification as you say but it will impose a cost to switching back and forth between, e.g., profiled and non-profiled versions. Do you actually use profiling with gprof? I've always used KCachegrind in the last few years instead. So IMHO its superflous anyway. Actually, no. My main encounter with switching was between debug+no optimization and non-debug+optimization. But the profiling case sounded like a more legitimate example. :-} Anyway I don't have a strong preference, just wanted to raise the possible issue. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
>> 1. remove the difference between shared_obj, shared_debug_obj, >> static_profile_obj, etc. too. Just use './obj' for everything >> (this is kind of a no-brainer, now that there is no longer any difference in the >> installed libraries, can't see any reason to keep a difference while >> building!). Another advantage is we no longer need a symlink here :-) > > This is probably best for simplification as you say but it will > impose a cost to switching back and forth between, e.g., profiled and > non-profiled versions. With the final library names merged you can > still switch between them by doing a new "make install" (which will > not require any compilation once you've built both), but merging > these build directories means a full recompilation is needed to make > the switch. Correct me if I'm missing something. Maybe it's not a > big deal since one can do a manual work-around. This is a very good and valid point :-) A good way of managing this after the simplification would be to use GNUSTEP_BUILD_DIR, which is already implemented, I'm just not sure how well it works across all project types (anyway it can be made to work). If we had a well-working GNUSTEP_BUILD_DIR, you could easily keep multiple builds of your source in different directories ... eg Eg, make GNUSTEP_BUILD_DIR=./non-debug make GNUSTEP_BUILD_DIR=./debug debug=yes make GNUSTEP_BUILD_DIR=./profile profile=yes make GNUSTEP_BUILD_DIR=./Experiment [...my flags...] That should work. GNUSTEP_BUILD_DIR works that if you don't specify a GNUSTEP_BUILD_DIR, everything is build by default in '.' (with the object files in './obj'). If you specify a GNUSTEP_BUILD_DIR, everything is built wherever you specify (eg, in ./non-debug, so you end up with ./non-debug/obj/libmystuff.so, ./non-debug/Gorm.app, ./non-debug/MyBundle.bundle, etc). Well, I guess we really need to get GNUSTEP_BUILD_DIR working properly for all projects ... another thing to do ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Sep 7, 2006, at 2:08 PM, Nicola Pero wrote: Well, I guess we really need to get GNUSTEP_BUILD_DIR working properly for all projects ... another thing to do ;-) Balaton has a patch to gnustep-make to get build-dir stuff working properly (or at least better) among other things. I'm still waiting for the assignment, but it's probably safe to apply if you want to take the time to look at it. I can forward the email to you. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On Thu, Sep 07, 2006 at 06:47:07PM +0200, Nicola Pero wrote: > Anyway, if anyone has any comments before I do all this simplification, > please let me know :-) I'm very much for this change. However, why not go one step further and have the -g standard? If you want non-debug versions you just do make strip=yes or something similar. With all the people compiling gnustep source anyways, why not leverage the ability to have backtraces on almost everybody with problems? The distros can do the stripping if they want... - Andy -- Andrew Ruder <[EMAIL PROTECTED]> http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
I'm agree with what Andy is saying. Later, GJC --Gregory Casamento - Original Message From: Andrew Ruder <[EMAIL PROTECTED]> To: gnustep-dev@gnu.org Sent: Thursday, September 7, 2006 11:09:51 PM Subject: Re: Removing all remaining distinction between shared, debug, profile and static libs/executables On Thu, Sep 07, 2006 at 06:47:07PM +0200, Nicola Pero wrote: > Anyway, if anyone has any comments before I do all this simplification, > please let me know :-) I'm very much for this change. However, why not go one step further and have the -g standard? If you want non-debug versions you just do make strip=yes or something similar. With all the people compiling gnustep source anyways, why not leverage the ability to have backtraces on almost everybody with problems? The distros can do the stripping if they want... - Andy -- Andrew Ruder <[EMAIL PROTECTED]> http://www.aeruder.net ___ 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: Removing all remaining distinction between shared, debug, profile and static libs/executables
Er. Dammit... when I type too fast I always screw up. :) *I* agree with what Andy is saying below. Thanks, GJC --Gregory Casamento - Original Message From: Gregory John Casamento <[EMAIL PROTECTED]> To: Andrew Ruder <[EMAIL PROTECTED]>; gnustep-dev@gnu.org Sent: Thursday, September 7, 2006 11:39:05 PM Subject: Re: Removing all remaining distinction between shared, debug, profile and static libs/executables I'm agree with what Andy is saying. Later, GJC --Gregory Casamento - Original Message From: Andrew Ruder <[EMAIL PROTECTED]> To: gnustep-dev@gnu.org Sent: Thursday, September 7, 2006 11:09:51 PM Subject: Re: Removing all remaining distinction between shared, debug, profile and static libs/executables On Thu, Sep 07, 2006 at 06:47:07PM +0200, Nicola Pero wrote: > Anyway, if anyone has any comments before I do all this simplification, > please let me know :-) I'm very much for this change. However, why not go one step further and have the -g standard? If you want non-debug versions you just do make strip=yes or something similar. With all the people compiling gnustep source anyways, why not leverage the ability to have backtraces on almost everybody with problems? The distros can do the stripping if they want... - Andy -- Andrew Ruder <[EMAIL PROTECTED]> http://www.aeruder.net ___ 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Hi, I'm not sure if the following problem relates to this clean-up, but after running a checkout, building and installing -make, I now get Making all for library libgnustep-base... Linking library libgnustep-base ... gcc41: debug=: No such file or directory gcc41: profile=: No such file or directory gmake[1]: Leaving directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/Source' Making all in SSL... gmake[1]: Entering directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/SSL' Making all for bundle SSL... Linking bundle SSL ... gcc41: debug=: No such file or directory gcc41: profile=: No such file or directory gmake[2]: *** [SSL.bundle/./SSL] Error 1 gmake[1]: *** [SSL.all.bundle.variables] Error 2 gmake[1]: Leaving directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/SSL' gmake: *** [internal-all] Error 2 -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Nicola Pero schrieb: > Anyway, if anyone has any comments before I do all this simplification, > please let me know :-) Thank you very much! Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Sorry about that ... I'll start to do a bit of simplification now and make sure I test building gnustep-base properly. :-) Thanks -Original Message- From: "Chris Vetter" <[EMAIL PROTECTED]> Sent: Friday, September 8, 2006 11:02 am To: gnustep-dev@gnu.org Subject: Re: Removing all remaining distinction between shared, debug, profile and static libs/executables Hi, I'm not sure if the following problem relates to this clean-up, but after running a checkout, building and installing -make, I now get Making all for library libgnustep-base... Linking library libgnustep-base ... gcc41: debug=: No such file or directory gcc41: profile=: No such file or directory gmake[1]: Leaving directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/Source' Making all in SSL... gmake[1]: Entering directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/SSL' Making all for bundle SSL... Linking bundle SSL ... gcc41: debug=: No such file or directory gcc41: profile=: No such file or directory gmake[2]: *** [SSL.bundle/./SSL] Error 1 gmake[1]: *** [SSL.all.bundle.variables] Error 2 gmake[1]: Leaving directory `/usr/local/SOURCE/GNUstep/Repos/gnustep/core/base/SSL' gmake: *** [internal-all] Error 2 -- Chris ___ 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: Removing all remaining distinction between shared, debug, profile and static libs/executables
Yes please! :-) Or even better put it on the savannah bugs/patches ? Thanks > > Well, I guess we really need to get GNUSTEP_BUILD_DIR working properly > > for all projects ... another thing to do ;-) > > Balaton has a patch to gnustep-make to get build-dir stuff working > properly (or at least better) among other things. I'm still waiting for > the assignment, but it's probably safe to apply if you want to take the > time to look at it. I can forward the email to you. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On 2006-09-08 12:39:11 +0200 Nicola Pero <[EMAIL PROTECTED]> wrote: Sorry about that ... I'll start to do a bit of simplification now and make sure I test building gnustep-base properly. :-) No problem. It's not just base, basically all .../Library/Makefile/Instance/*.make files are 'involved' I tried to 'make debug=no profile=no shared=yes' which didn't help either (same message) but when I started to edit the above mentioned xyz.make files (eg. library.make, application.make and so on) and removed the lines containing debug=$(debug) profile=$(profile) shared=$(shared) \ everything compiled cleanly again. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Please try again now ... which_lib is gone!! :-) Works for me anyway. Thanks -Original Message- From: "Chris Vetter" <[EMAIL PROTECTED]> Sent: Friday, September 8, 2006 1:10 pm To: [EMAIL PROTECTED] Cc: gnustep-dev@gnu.org Subject: Re: Removing all remaining distinction between shared, debug, profile and static libs/executables On 2006-09-08 12:39:11 +0200 Nicola Pero <[EMAIL PROTECTED]> wrote: > Sorry about that ... I'll start to do a bit of simplification now and > make > sure I test building gnustep-base properly. :-) No problem. It's not just base, basically all .../Library/Makefile/Instance/*.make files are 'involved' I tried to 'make debug=no profile=no shared=yes' which didn't help either (same message) but when I started to edit the above mentioned xyz.make files (eg. library.make, application.make and so on) and removed the lines containing debug=$(debug) profile=$(profile) shared=$(shared) \ everything compiled cleanly again. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
On 2006-09-08 13:19:54 +0200 Nicola Pero <[EMAIL PROTECTED]> wrote: Please try again now ... which_lib is gone!! :-) Works for me anyway. Confirmed. Works again. Cool, -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Sorry for the late reply, I was on vacation for the past couple weeks... On Thu, 7 Sep 2006 18:47:07 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: > Adam has removed the '_d' library name suffix for debug libraries > ... a very welcome change which will make everything simpler and less > liable to break :-) > I think having done this, we lost the ability to have debug and > non-debug libs at the same time, so we can simplify everything a lot > ... without losing much more, since we have already done the big > sacrifice ;-) In Debian, with other libraries, what is usually done is the debug libs get installed in /usr/lib/debug, and the regular libs get installed in /usr/lib. Then, if you want to use the debug versions, you just set LD_LIBRARY_PATH. So you can do something similar here if you really want both versions installed. > 1. remove the difference between shared_obj, shared_debug_obj, > static_profile_obj, etc. too. Just use './obj' for everything (this > is kind of a no-brainer, now that there is no longer any difference in > the installed libraries, can't see any reason to keep a difference > while building!). Another advantage is we no longer need a symlink > here :-) I would prefer keeping the shared_obj and shared_debug_obj directories, since it makes compiling Debian packages easier (so that I can compile the regular and debug versions at the same time). But if you want to remove the distinction, this can probably be worked around. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) 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
