gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Removing all remaining distinction between shared, debug, profile and st


From: Nicola Pero
Subject: Removing all remaining distinction between shared, debug, profile and static libs/executables
Date: Thu, 7 Sep 2006 18:47:07 +0200 (CEST)

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]