[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #48348] gnustep-config doesn't do what I want
From: |
Richard Frith-Macdonald |
Subject: |
[bug #48348] gnustep-config doesn't do what I want |
Date: |
Thu, 30 Jun 2016 07:25:29 +0000 (UTC) |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 |
Update of bug #48348 (project gnustep):
Summary: gnustep-config output is unusable => gnustep-config
doesn't do what I want
_______________________________________________________
Follow-up Comment #1:
gnustep-config was written as a quick solution to provide an easy way to
locate gnustep-make and the rest of the gnustep installation, and also to
expose some of the internals of gnustep-make and to allow
building/installation of simple cases in the same way that gnustep-make would
do it (eg when you just want to build using a shell script rather than writing
a make file).
So if/when you want to do things a different way (eg link using the linker
directly rather than via the compiler), it's going to be suboptimal and
require extra work (eg a need to filter the compiler options out). Also, of
course it provides a load of stuff you don't happen to want, but other people
do.
That being said, it's close enough to the functionality you are expecting,
that I can imagine how frustrating it must be to find it actually does
something different, and I know that there are other people who might want
similar facilities to the ones you want (generally everyone wants something
slightly different, but there's a lot of commonality too).
I think patches to improve this state would be very welcome:
1. change the documentation of the script to make it clearer what each option
does
2. add new options to do the things that you specifically want (this may
require you to change gnustep-make internals. (in your example it sounds like
we would want to hold compiler link options and linker link options in
separate variables rather than a single variable).
3. even rename existing options (though this would need to involve adding the
new name of the option, deprecating the old one, and then removing support for
the old version in successive releases ... allowing people time to change
their code).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?48348>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/