Wed 13 May 2015 09:05:35 PM UTC, comment #11:
All agreed to warn only. Richard, I imported your base version now in gui and back.
|
Tue 12 May 2015 07:31:52 PM UTC, comment #10:
I agree. This is an issue. Please don't forget to also add it to back.
|
Tue 12 May 2015 06:46:10 PM UTC, comment #9:
let's separate two issues
1) all the libraries (but all programs) should be compiled consistently. make remembers your compiler usually, it is configure that needs to be hinted. That is just correct or you end up with a mess. I fixed that in gui, back and GWorkspace now
2) you may provide an alternate CC and it takes precedence, thus what you pass as variables gets respected, we just set a more sensible default!
3) there is a check in base, which I copied to the other projects too which checks that the current compiler is the same as of make.
MAKECC=`gnustep-config --variable=CC`
if test "$CC" != "$MAKECC"; then
AC_MSG_ERROR([You are running configure with the compiler ($CC) set to a different value from that used by gnustep-make ($MAKECC). Please run configure again with your environment set to match your gnustep-make])
exit 1
fi
I think 1) and 2) are just sensible points. 3) is actually helping not to shoot in your feet but it is a hinderance to power users like Matt. You might be running "gcc" vs "gcc-beta" knowing yourself that they generate compatible code.
should the check be removed? or perhaps it can be made a warning? We can change it to AC_MSG_WARN what do you think?
for the average user everything should be fine, but Matt can do his special tricks too.
|
Tue 12 May 2015 05:31:58 PM UTC, comment #8:
In the cases I found this annoying it was largely doing compiler work and comparing the output of an unmodified compiler with the output of an in-progress one, if you build things incorrectly of course they won't work regardless of whether gnustep-make thinks it knows better than the user or not.
These environment variables exist as environment variables precisely so that the user can change them.
|
Tue 12 May 2015 05:09:44 PM UTC, comment #7:
I don't agree with that argument, but even if I did, it still has nothing to do with this issue.
This issue is about having autoconf (ie the configure script) default to using the same compiler that you use when you build.
It makes little sense to configure using one compiler and then build using a different compiler ... mostly it'll work, but sometimes the difference will mean that the results of the configure script will not be workable when you build the software. Usually the compiler makes no difference, but sometimes you will get a compile error, sometime link errors, and worst of all runtime errors which are really hard to track down.
|
Tue 12 May 2015 04:52:31 PM UTC, comment #6:
> The gnustep-make -> libobjc -> gnustep-make sequence before
> configuring base is about making sure base is configured with
> the version of libobjc you actually intend to use (because base has
> to be aware of what libobjc it's going to be used with).
> It's a different thing to this issue.
Not really its an argument that gnustep-make/base shouldn't do this in the first place, it's irritating when you set some flags for use in the compile when gnustep-make then goes and does what it was configured to use rather than what you just told it to do.
|
Tue 12 May 2015 04:25:03 PM UTC, comment #5:
> it enforced an installation process of the form
> gnustep-make -> libobjc -> gnustep-make -> gnustep-base
The gnustep-make -> libobjc -> gnustep-make sequence before configuring base is about making sure base is configured with the version of libobjc you actually intend to use (because base has to be aware of what libobjc it's going to be used with).
It's a different thing to this issue.
|
Tue 12 May 2015 03:08:54 PM UTC, comment #4:
I recall finding this behavior of gnustep-make/gnustep-base irritating when compiling the very old outside of gcc libobjc, in that it enforced an installation process of the form
gnustep-make -> libobjc -> gnustep-make -> gnustep-base
|
Tue 12 May 2015 02:48:41 PM UTC, comment #3:
I'm inclined to agree with Riccardo.
I'd call it a request for improvement rather than a bug report though.
What base does (I hope) when you run configure:
1. see if you explicitly specified what compiler to use
2. see what compiler gnustep-make was configured to use
3. see what compiler standard autoconf macros can find
That means, if you just run configure for base, it should use the same compiler that was used when configuring gnustep-make, so all the correct compiler flags should be found automatically.
If you explicitly specified a compiler that's NOT what gnustep-make was configured to use, then theres a high chance that incompatibilities will occur, so it should bomb out with an error message, giving you a chance to fixup your environment and/or reconfigure gnustep-make for the new compiler.
I guess it's not unreasonable that we might want to put similar intelligence/error-checking into the gui and back configure scripts.
|
Tue 12 May 2015 09:16:20 AM UTC, comment #2:
for base it works, this is why I ask.
If it can be made work for everythin, I would prefer that, much much more user-friendly! I would then import the fix in GWorkspace.
By default configure does't import anything. I think this is the bit in base that does the magic:
1048 #--------------------------------------------------------------------
1049 # Find the compiler
1050 #--------------------------------------------------------------------
1051 if test "$CC" = ""; then
1052 CC=`gnustep-config --variable=CC`
1053 fi
1054 if test "$CPP" = ""; then
1055 CPP=`gnustep-config --variable=CPP`
1056 fi
1057 if test "$CXX" = ""; then
1058 CXX=`gnustep-config --variable=CXX`
1059 fi
1060 AC_PROG_CC
1061 AC_PROG_CPP
1062 AC_USE_SYSTEM_EXTENSIONS
1063
1064 MAKECC=`gnustep-config --variable=CC`
1065 if test "$CC" != "$MAKECC"; then
1066 AC_MSG_ERROR([You are running configure with the compiler ($CC) set to a different value from that used by gnustep-make ($MAKECC). Please run configure again with your environment set to match your gnustep-make])
1067 exit 1
1068 fi
1069
|
Tue 12 May 2015 08:57:37 AM UTC, comment #1:
I'm not sure this bug is valid. The way autoconf works, it will need you to respecify CC and CXX every time you do configure. Nicola or Richard, can you confirm this?
|
Tue 12 May 2015 08:17:53 AM UTC, original submission:
when gnustep-make is configured specifying CC and CXX, base correctly configures using those values, gui and back do not and look for the standard compiler.
|