Just a normal build: but a strange configure error did occur.
$$$
checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 configure: error: No C++ compiler not found. Please install a C++ compiler.
$$$
I found it's just a ``which`` in configure.in.
QQQ
# check for C++ compiler explicitly and fail if none is found, do this check # after AC_PROG_CXX has set the CXX environment variable which $CXX >/dev/null 2>&1 if test "x$?" != "x0"; then AC_MSG_ERROR([No C++ compiler not found. Please install a C++ compiler.]) fi
QQQ
I didn't know that the ``which`` utility was considered a compiler. :p
How about just using a shell builtin, ``hash``, ``type -P`` or just ``eval $CXX --version`` as a test instead?
------------------------------------------------------------------ configure.in:18 : which $CXX >/dev/null 2>&1 configure.in:51 : GIT=`which git 2>/dev/null` configure.in:60 : SVN=`which svn 2>/dev/null` Found 3 matches for "which".
On Friday 11,September,2009 09:58 AM, Erik Southworth wrote:
[...] I didn't know that the ``which`` utility was considered a compiler. :p
It isn't, but it searches your $PATH for the full path of a utility, $CXX being the utility it's searching for. (CXX is a variable containing its name). AFAIK, which is a coreutils utility, so it should work on all systems capable of executing a shell script. In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work. Chances are that your $CXX is not defined to a correct variable.
How about just using a shell builtin, ``hash``, ``type -P`` or just ``eval $CXX --version`` as a test instead?
Does $CXX --version really exist with all C++ compilers?
configure.in:18 : which $CXX >/dev/null 2>&1 configure.in:51 : GIT=`which git 2>/dev/null` configure.in:60 : SVN=`which svn 2>/dev/null` Found 3 matches for "which".
The last two are required to get the full path of git and svn into $GIT and $SVN. The first is harmless for reasons mentioned above.
On Fri, Sep 11, 2009 at 12:34 AM, Chow Loong Jin hyperair@gmail.com wrote:
On Friday 11,September,2009 09:58 AM, Erik Southworth wrote:
[...] I didn't know that the ``which`` utility was considered a compiler. :p
It isn't, but it searches your $PATH for the full path of a utility, $CXX being the utility it's searching for. (CXX is a variable containing its name).
To be clear, if we don't have ``which`` it shouldn't error about a c++ compiler. Also, (1) if we must have ``which``, configure should check for it before trying to use it. (2) If we need to check a prog use AC_CHECK_PROG or AC_PATH_PROG.
AFAIK,
which is a coreutils utility, so it should work on all systems capable of executing a shell script.
No. It's not part of coreutils.
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
Chances are that your $CXX is not defined to a correct variable.
How about just using a shell builtin, ``hash``, ``type -P`` or just
``eval
$CXX --version`` as a test instead?
Does $CXX --version really exist with all C++ compilers?
Bottom line: we should use portable autoconf macros not random system utilities.
configure.in:18 : which $CXX >/dev/null 2>&1 configure.in:51 : GIT=`which git 2>/dev/null` configure.in:60 : SVN=`which svn 2>/dev/null` Found 3 matches for "which".
The last two are required to get the full path of git and svn into $GIT and $SVN. The first is harmless for reasons mentioned above.
-- Kind regards, Chow Loong Jin
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 11 Sep 2009 14:06:38 -0400 Erik Southworth erik.southworth@gmail.com wrote:
To be clear, if we don't have ``which`` it shouldn't error about a c++ compiler. Also, (1) if we must have ``which``, configure should check for it before trying to use it. (2) If we need to check a prog use AC_CHECK_PROG or AC_PATH_PROG.
AFAIK,
which is a coreutils utility, so it should work on all systems capable of executing a shell script.
No. It's not part of coreutils.
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
Chances are that your $CXX is not defined to a correct variable.
How about just using a shell builtin, ``hash``, ``type -P`` or just
``eval
$CXX --version`` as a test instead?
Does $CXX --version really exist with all C++ compilers?
Bottom line: we should use portable autoconf macros not random system utilities.
If you provide a patch that does it portably we would likely apply it.
Regards, Nick
On Sat, Sep 12, 2009 at 12:37 PM, Nick Treleaven < nick.treleaven@btinternet.com> wrote:
On Fri, 11 Sep 2009 14:06:38 -0400 Erik Southworth erik.southworth@gmail.com wrote:
To be clear, if we don't have ``which`` it shouldn't error about a c++ compiler. Also, (1) if we must have ``which``, configure should check for
it
before trying to use it. (2) If we need to check a prog use AC_CHECK_PROG
or
AC_PATH_PROG.
AFAIK,
which is a coreutils utility, so it should work on all systems capable
of
executing a shell script.
No. It's not part of coreutils.
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even
work.
It's that Geany is built in a clean chroot build environment along with
only
the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary
prog
and forces users to figure out which ones are needed.
Chances are that your $CXX is not defined to a correct variable.
How about just using a shell builtin, ``hash``, ``type -P`` or just
``eval
$CXX --version`` as a test instead?
Does $CXX --version really exist with all C++ compilers?
Bottom line: we should use portable autoconf macros not random system utilities.
If you provide a patch that does it portably we would likely apply it.
Here is a patch against Rev 4190 in Trunk.
Regards,
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 15 Sep 2009 13:54:30 -0400 Erik Southworth erik.southworth@gmail.com wrote:
Here is a patch against Rev 4190 in Trunk.
Committed, thanks. I changed the COMPILER variable name to CXXCOMPILER.
Regards, Nick
On Fri, 11 Sep 2009 14:06:38 -0400, Erik wrote:
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
The whole reason for using "which" was to be more portable. The autoconf macros you mention are broken or at least not usable for checking for a C++ compiler (or I'm too stupid, then they are just to hard to use).
As Nick said, if it is such an issue and you know it that better, we would be happy about a sane patch to improve things.
Regards, Enrico
On Tue, 15 Sep 2009 19:27:37 +0200, Enrico wrote:
On Fri, 11 Sep 2009 14:06:38 -0400, Erik wrote:
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
The whole reason for using "which" was to be more portable. The autoconf macros you mention are broken or at least not usable for checking for a C++ compiler (or I'm too stupid, then they are just to hard to use).
As Nick said, if it is such an issue and you know it that better, we would be happy about a sane patch to improve things.
This patch actually reduced portability.
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=2973764...
Solutions would be welcome.
Regards, Enrico
2010/3/21 Enrico Tröger enrico.troeger@uvena.de
On Tue, 15 Sep 2009 19:27:37 +0200, Enrico wrote:
On Fri, 11 Sep 2009 14:06:38 -0400, Erik wrote:
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
The whole reason for using "which" was to be more portable. The autoconf macros you mention are broken or at least not usable for checking for a C++ compiler (or I'm too stupid, then they are just to hard to use).
As Nick said, if it is such an issue and you know it that better, we would be happy about a sane patch to improve things.
This patch actually reduced portability.
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=2973764...
Solutions would be welcome.
Hi Enrico,
As you know I'm AC_phobic but, as I understand the comment in configure.acthe idea is to actually confirm that AC_PROG_CXX found the right thing.
Isn't the best way to do this to actually compile something simple and see if it works rather than testing for existance of the executable? Maybe just compile the definition of a global variable.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 21 Mar 2010 10:53:25 +1100, Lex wrote:
2010/3/21 Enrico Tröger enrico.troeger@uvena.de
On Tue, 15 Sep 2009 19:27:37 +0200, Enrico wrote:
On Fri, 11 Sep 2009 14:06:38 -0400, Erik wrote:
In fact, I think there are many system scripts which use 'which', so if you don't have 'which', your system shouldn't even work.
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
The whole reason for using "which" was to be more portable. The autoconf macros you mention are broken or at least not usable for checking for a C++ compiler (or I'm too stupid, then they are just to hard to use).
As Nick said, if it is such an issue and you know it that better, we would be happy about a sane patch to improve things.
This patch actually reduced portability.
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=2973764...
Solutions would be welcome.
Hi Enrico,
As you know I'm AC_phobic but, as I understand the comment in
Same here :).
configure.acthe idea is to actually confirm that AC_PROG_CXX found the right thing.
Isn't the best way to do this to actually compile something simple and see if it works rather than testing for existance of the executable? Maybe just compile the definition of a global variable.
Maybe. But from reading the code I'd expect it would work. I don't know how AC_PATH_PROG works but I guess it should be able to find a program if its full path is passed, that's the easiest case it could have. But also, I never understood the autotools stuff really. In the early Geany days I just copied it from other projects as all others did and then later I for myself switched to Waf which works way smoother, for me.
Maybe Erik has an idea.
Regards, Enrico
On Sat, 20 Mar 2010 17:31:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
It's that Geany is built in a clean chroot build environment along with only the compilers and libs required. ``which`` is not a necessary build requirement IMHO. We should have a portable, standard, ``configure`` that can build Geany, not a system utility script that calls any arbitrary prog and forces users to figure out which ones are needed.
The whole reason for using "which" was to be more portable. The autoconf macros you mention are broken or at least not usable for checking for a C++ compiler (or I'm too stupid, then they are just to hard to use).
As Nick said, if it is such an issue and you know it that better, we would be happy about a sane patch to improve things.
This patch actually reduced portability.
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=2973764...
Solutions would be welcome.
I think we should just revert the change. Depending on 'which' is not too bad. I wish I hadn't committed it now ;-/
In the original use case, perhaps they could just copy 'which' into the chroot environment.
Regards, Nick
On Thu, 25 Mar 2010 18:11:15 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
This patch actually reduced portability.
https://sourceforge.net/tracker/?func=detail&atid=787791&aid=2973764...
Solutions would be welcome.
I think we should just revert the change. Depending on 'which' is not too bad.
Now reverted. It's not great that systems without 'which' print an error message about a missing C++ compiler, but at least this should be very rare.
Regards, Nick