Re: [CMake] several questions about cmake
Hi Michael,
The quadruple slashes fixed the problem, thanks!
And it turns out that it is valid C++ to have
void main()
because it's valid C.
Source:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html
It would have made me very nervous to change the validation code from
the given configure.in file to change the return type, since I'm
imagining platforms that are distinct from mine (ie, unixy, and
therefore building C++ on top of C and not correcting the main return
type).
Thanks!
Mark
--
Message: 3
Date: Thu, 26 Aug 2010 23:10:09 +0200
From: Michael Hertling mhertl...@online.de
Subject: Re: [CMake] several questions about cmake
To: cmake@cmake.org
Message-ID: 4c76d831.5080...@online.de
Content-Type: text/plain; charset=ISO-8859-1
On 08/26/2010 05:38 PM, Mark Roden wrote:
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
Just put \ in front of the quotation marks, and the hello world code will
work.
That's not my point. The code I gave has no double quotes in it, and
it still doesn't compile properly, but it does compile and work in a
visual studio environment.
If I do:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
strcpy(buf, \Hello world\n\);
} EXTERN_C)
I get
Performing Test EXTERN_C
Performing Test EXTERN_C - Failed
But that code compiles in an empty vs2008 project.
How can I get the compiler error? I don't see why this code test should
fail.
You need to escape the newline in the string literal four-fold, i.e.
\Hello worldn\. Moreover, void isn't allowed as the return
type of main() in C++, use int instead.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
Hi Jed, I don't want portable code. I want the socket++ code that I originally got from someone else to compile as intended on the various platforms they support. They put a void as a return type; that void as a return type is compiling just fine on vs2008, which according to that page, is perfectly legal behavior for that compiler. This code is part of a config file, so I figure that if the test fails, then that means that socket++ was intended to run with extern 'c' wrapping around various functions. Are they correct? I don't know. Does it work for me? Yes. You are right that C++ is not a strict superset of C ( at least according to http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B; I'm a big fan of sources), but in this instance, it looks like some compiler vendors were under that impression. I can only assume that the original authors of the library were as well, and wrote their code accordingly. I don't have the expertise in their domain (networking) to be provide useful debugging. Thanks, Mark On Fri, Aug 27, 2010 at 8:30 AM, Jed Brown j...@59a2.org wrote: On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden mmro...@gmail.com wrote: And it turns out that it is valid C++ to have void main() because it's valid C. Source: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html You seem to have misread the link (which appears to falsely assert that otherwise its type is implementation-defined is functionally different from some other implementation-defined manner). The validity is implementation-defined, it is not standard C or C++. And C++ is not a superset of C (far from it), so even if the C standard did guaratee that returning void was supported (it doesn't), it would not imply that C++ supports it. If you want portable code, main must return int. Jed ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
c++'98 standard (http://www.kuzbass.ru:8086/docs/isocpp/basic.html#basic.start.main) clearly states that main _MUST_ have int as it's return type. Further it shall be callable as int main(); int main(int argc, char* argv[]); The part that says but otherwise its type is implementation-defined refers to the function arguments which are implementation-defined (except for the above two forms). E.g. most implementations also pass a pointer to a table containing environment variables, on Mac OS X you get additionally a pointer to an so-called apple-argument vector, containing e.g. the absolute path of the executable (where argv[0] in contrast can contain an arbitrary string if main is e.g. called by execve()). So, any conforming compiler MUST accept int main(), while void main() is a compiler extension, and probably supported by some compilers to accommodate pre-ISO standard code. And the test is probably more concerned with the fact that sometimes on very old/bad systems you need to surround things like #include stdio.h with extern C statements because the implementors of the C standard library didn't do so. Michael On 27. Aug, 2010, at 17:45 , Mark Roden wrote: Hi Jed, I don't want portable code. I want the socket++ code that I originally got from someone else to compile as intended on the various platforms they support. They put a void as a return type; that void as a return type is compiling just fine on vs2008, which according to that page, is perfectly legal behavior for that compiler. This code is part of a config file, so I figure that if the test fails, then that means that socket++ was intended to run with extern 'c' wrapping around various functions. Are they correct? I don't know. Does it work for me? Yes. You are right that C++ is not a strict superset of C ( at least according to http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B; I'm a big fan of sources), but in this instance, it looks like some compiler vendors were under that impression. I can only assume that the original authors of the library were as well, and wrote their code accordingly. I don't have the expertise in their domain (networking) to be provide useful debugging. Thanks, Mark On Fri, Aug 27, 2010 at 8:30 AM, Jed Brown j...@59a2.org wrote: On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden mmro...@gmail.com wrote: And it turns out that it is valid C++ to have void main() because it's valid C. Source: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html You seem to have misread the link (which appears to falsely assert that otherwise its type is implementation-defined is functionally different from some other implementation-defined manner). The validity is implementation-defined, it is not standard C or C++. And C++ is not a superset of C (far from it), so even if the C standard did guaratee that returning void was supported (it doesn't), it would not imply that C++ supports it. If you want portable code, main must return int. Jed ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden mmro...@gmail.com wrote: And it turns out that it is valid C++ to have void main() because it's valid C. Source: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html You seem to have misread the link (which appears to falsely assert that otherwise its type is implementation-defined is functionally different from some other implementation-defined manner). The validity is implementation-defined, it is not standard C or C++. And C++ is not a superset of C (far from it), so even if the C standard did guaratee that returning void was supported (it doesn't), it would not imply that C++ supports it. If you want portable code, main must return int. Jed ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
Sorry about breaking the back-thread, I only saw the response in the
cmake digest and not from a particular response.
I think that this code is suspicious anyway, for a number of reasons.
They claim out-of-the-box windows compatibility, but I'm getting all
sorts of other compilation errors that indicate that this code isn't
of the highest Windows quality. For instance, neglecting these two
defines:
# define ENAMETOOLONG WSAENAMETOOLONG
# define ENOTEMPTYWSAENOTEMPTY
and assuming that sys/signal.h exists across all platforms while not
making the same assumption about sys/types.h.
Looks like I'm gonna have to (re)learn sockets, at least enough to
polish this up to make it useful.
To paraphrase Homer J:
Learning? That wasn't part of the deal!
Ah well :)
Thanks for the help,
Mark
On Fri, Aug 27, 2010 at 9:31 AM, Jed Brown j...@59a2.org wrote:
Quoth Stroustrup (http://www2.research.att.com/~bs/bs_faq2.html#void-main):
The definition
void main() { /* ... */ }
is not and never has been C++, nor has it even been C. See the ISO C++
standard 3.6.1[2] or the ISO C standard 5.1.2.2.1. A conforming
implementation accepts
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }
A conforming implementation may provide more versions of main(), but
they must all have return type int. The int returned by main() is a way
for a program to return a value to the system that invokes it. On
systems that doesn't provide such a facility the return value is
ignored, but that doesn't make void main() legal C++ or legal C. Even
if your compiler accepts void main() avoid it, or risk being
considered ignorant by C and C++ programmers.
Mark, you may be correct that it's not the reason for the failure (I
haven't read the back-thread, which you broke) but I would be very
suspicious of code that is non-conforming.
Jed
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On 26 August 2010 01:34, Mark Roden mmro...@gmail.com wrote:
I'm starting to get deep into CMake, and I have a few questions as I
try to convert the socket++ library such that it can be compiled by
CMake on Windows.
1) The default install directory on Windows is C:\Program Files, or
C:\Program Files (x86) on 64 bit. This default will not work on
Windows 7 (and perhaps Vista), because the user isn't running as
administrator anymore, and only administrators can modify that
directory. There should probably be a warning to that effect on
windows systems; otherwise, there are painful ways to run install, but
they are painful.
Most developers run as administrator so I don't think there should be a warning.
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
You can use quotes by doing \ rather than .
3) There is a check for the presence of the Libg++ library, but no
specific mention of which function is needed. According to what I can
find on CheckLibraryExists, I need to provide a specific function to
determine if that library is present. The code in configure.in is:
AC_CHECK_HEADER(_G_config.h, AC_DEFINE(_S_LIBGXX))
In that case, should I be looking for a particular function in
_G_config.h (which I don't have, since I'm on Windows) and just using
it arbitrarily? I'm not even close to the point where this code can
fail in compilation and therefore determine the error directly.
I don't think you need to check for that library, certainly not on Windows.
4) There are two checks for potentially predefined variables, namely
sys_siglist and sys_errlist. The code to check for these looks like:
AC_CACHE_VAL(socketxx_cv_siglist, [
AC_TRY_LINK([
# include unistd.h
# include sys/signal.h
], [
#ifndef _sys_siglist
extern char* _sys_siglist[];
#endif
puts(*_sys_siglist);
],
socketxx_cv_siglist=_sys_siglist,
socketxx_cv_siglist=sys_siglist) ])
AC_DEFINE_UNQUOTED(SYS_SIGLIST, $socketxx_cv_siglist)
Windows doesn't have unistd.h or sys/signal.h, so I know that this
will fail, regardless of the test. I'm unfamiliar with these
variables; does anyone have any insight into them? It looks like if
the code compiles, the variable _sys_siglist will be used, otherwise,
sys_siglist, whatever that is. I'm tempted to just say that it is
what it is, and if other unix users have issues, we can fix the cmake
file then. The typical sloppiness of someone not dealing with their
native platform, I guess :)
There are other problems with converting this file, but I want to
start with this one and still hack away at the others.
I'd recommend looking at the manpages for these functions and trying
to find a native equivalent you can check for and extend the check.
I wouldn't try and copy all the autoconf checks exactly, just get your
project building first and then create the ones you actually need.
--
Cheers,
Mike McQuaid
http://mikemcquaid.com/
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On 26. Aug, 2010, at 1:34 , Mark Roden wrote:
I'm starting to get deep into CMake, and I have a few questions as I
try to convert the socket++ library such that it can be compiled by
CMake on Windows.
Cool!
1) The default install directory on Windows is C:\Program Files, or
C:\Program Files (x86) on 64 bit. This default will not work on
Windows 7 (and perhaps Vista), because the user isn't running as
administrator anymore, and only administrators can modify that
directory. There should probably be a warning to that effect on
windows systems; otherwise, there are painful ways to run install, but
they are painful.
I hope you will create an installer using CPack, and most users will then use
that instead of compiling from sources, so IMHO that is no real problem.
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
Just put \ in front of the quotation marks, and the hello world code will work.
3) There is a check for the presence of the Libg++ library, but no
specific mention of which function is needed. According to what I can
find on CheckLibraryExists, I need to provide a specific function to
determine if that library is present. The code in configure.in is:
AC_CHECK_HEADER(_G_config.h, AC_DEFINE(_S_LIBGXX))
In that case, should I be looking for a particular function in
_G_config.h (which I don't have, since I'm on Windows) and just using
it arbitrarily? I'm not even close to the point where this code can
fail in compilation and therefore determine the error directly.
In that case I just find a sufficiently unique function in libg++ (using e.g.
the nm tool on Unix systems or dumpbin on Windows). But what above code
actually does corresponds to
find_file(G_CONFIG_H_PATH _G_config.h)
if(G_CONFIG_H_PATH)
set(_S_LIBGXX 1)
else()
set(_S_LIBGXX 0)
endif()
Actually, it does a bit more (see the docs of AC_DEFINE), but I don't think it
is relevant to you.
4) There are two checks for potentially predefined variables, namely
sys_siglist and sys_errlist. The code to check for these looks like:
AC_CACHE_VAL(socketxx_cv_siglist, [
AC_TRY_LINK([
# include unistd.h
# include sys/signal.h
], [
#ifndef _sys_siglist
extern char* _sys_siglist[];
#endif
puts(*_sys_siglist);
],
socketxx_cv_siglist=_sys_siglist,
socketxx_cv_siglist=sys_siglist) ])
AC_DEFINE_UNQUOTED(SYS_SIGLIST, $socketxx_cv_siglist)
Windows doesn't have unistd.h or sys/signal.h, so I know that this
will fail, regardless of the test. I'm unfamiliar with these
variables; does anyone have any insight into them? It looks like if
the code compiles, the variable _sys_siglist will be used, otherwise,
sys_siglist, whatever that is. I'm tempted to just say that it is
what it is, and if other unix users have issues, we can fix the cmake
file then. The typical sloppiness of someone not dealing with their
native platform, I guess :)
Those are definitely unixy, they contain operating system signal and error
descriptions and are usually accessed through the psginal, strsignal, perror
and strerror family of functions. Normally they should not be accessed
directly. I think the above code assumes it's running on Unix and just
determines whether the C library implementor prefixed the variables with a _
(to mark them for internal use only).
There are other problems with converting this file, but I want to
start with this one and still hack away at the others.
Thanks!
Mark
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
-Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Mike McQuaid Sent: Thursday, August 26, 2010 1:12 AM To: Mark Roden Cc: cmake@cmake.org Subject: Re: [CMake] several questions about cmake On 26 August 2010 01:34, Mark Roden mmro...@gmail.com wrote: I'm starting to get deep into CMake, and I have a few questions as I try to convert the socket++ library such that it can be compiled by CMake on Windows. 1) The default install directory on Windows is C:\Program Files, or C:\Program Files (x86) on 64 bit. This default will not work on Windows 7 (and perhaps Vista), because the user isn't running as administrator anymore, and only administrators can modify that directory. There should probably be a warning to that effect on windows systems; otherwise, there are painful ways to run install, but they are painful. Most developers run as administrator so I don't think there should be a warning. In Windows 7 and Windows 2008 server, being logged in as a user in the Administrators group is not sufficient, you have to elevate the privs of your process to write in those directories. Another possibility is turning off UAC all together. So the warning might still be a good idea. -Kelly ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On Wed, Aug 25, 2010 at 11:17 PM, Michael Wild them...@gmail.com wrote:
On 26. Aug, 2010, at 1:34 , Mark Roden wrote:
I'm starting to get deep into CMake, and I have a few questions as I
try to convert the socket++ library such that it can be compiled by
CMake on Windows.
Cool!
Thanks, I think so to :)
1) The default install directory on Windows is C:\Program Files, or
C:\Program Files (x86) on 64 bit. This default will not work on
Windows 7 (and perhaps Vista), because the user isn't running as
administrator anymore, and only administrators can modify that
directory. There should probably be a warning to that effect on
windows systems; otherwise, there are painful ways to run install, but
they are painful.
I hope you will create an installer using CPack, and most users will then use
that instead of compiling from sources, so IMHO that is no real problem.
I generally intend to create an installer using WiX, mainly out of
ignorance of CPack and extensive experience using WiX. Not that WiX
is better-- it has some serious usability problems-- but it integrates
nicely with visual studio.
However, I'm more talking about when I run CMake to install on my own machine.
My work paradigm runs like this:
1) get all the libraries I need
2) compile them all
3) put the libraries and headers into a file
4) make my own project in visual studio
5) reference those libraries and headers in my project
Why not put it all into CMake, I hear you cry? A few reasons:
1) For the longest time (and still ongoing), the gdcm version in itk
doesn't match the latest greatest from gdcm. There is a compiler
switch to use 'system gdcm', whatever that means on Windows, but other
projects I have require the 1.2 branch in itk. So I can (and do) have
multiple versions of itk to account for this, and so need to ensure I
reference the right one.
2) I'm generally not messing directly with the libraries I install via
cmake, I just compile against them and use provided functions. Going
through the cmakelists process is not helpful when I'm just using the
libraries as is. When I modify the libraries, then I use CMake,
because that's the way these libraries come.
3) Since I don't want to recompile the libraries on multiple machines,
I just check in the results of running the installation into source
control. This works great when you're deploying on windows;
everything compiles and builds on one machine will work on another, so
reproducing my dev environment, either for a coworker or for myself on
another machine, is much simpler and saves more time than getting the
source, making sure it's the same source as what I started with, and
rebuilding again.
So, yes, a warning would be very nice, given the way that I use the
installation option in CMake.
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
Just put \ in front of the quotation marks, and the hello world code will
work.
That's not my point. The code I gave has no double quotes in it, and
it still doesn't compile properly, but it does compile and work in a
visual studio environment.
If I do:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
strcpy(buf, \Hello world\n\);
} EXTERN_C)
I get
Performing Test EXTERN_C
Performing Test EXTERN_C - Failed
But that code compiles in an empty vs2008 project.
How can I get the compiler error? I don't see why this code test should fail.
3) There is a check for the presence of the Libg++ library, but no
specific mention of which function is needed. According to what I can
find on CheckLibraryExists, I need to provide a specific function to
determine if that library is present. The code in configure.in is:
AC_CHECK_HEADER(_G_config.h, AC_DEFINE(_S_LIBGXX))
In that case, should I be looking for a particular function in
_G_config.h (which I don't have, since I'm on Windows) and just using
it arbitrarily? I'm not even close to the point where this code can
fail in compilation and therefore determine the error directly.
In that case I just find a
Re: [CMake] several questions about cmake
On Thu, Aug 26, 2010 at 6:47 AM, Hickel, Kelly kelly_hic...@bmc.com wrote: -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Mike McQuaid Sent: Thursday, August 26, 2010 1:12 AM To: Mark Roden Cc: cmake@cmake.org Subject: Re: [CMake] several questions about cmake On 26 August 2010 01:34, Mark Roden mmro...@gmail.com wrote: I'm starting to get deep into CMake, and I have a few questions as I try to convert the socket++ library such that it can be compiled by CMake on Windows. 1) The default install directory on Windows is C:\Program Files, or C:\Program Files (x86) on 64 bit. This default will not work on Windows 7 (and perhaps Vista), because the user isn't running as administrator anymore, and only administrators can modify that directory. There should probably be a warning to that effect on windows systems; otherwise, there are painful ways to run install, but they are painful. Most developers run as administrator so I don't think there should be a warning. In Windows 7 and Windows 2008 server, being logged in as a user in the Administrators group is not sufficient, you have to elevate the privs of your process to write in those directories. Another possibility is turning off UAC all together. So the warning might still be a good idea. I agree. Installing on these systems even as administrator to the default location C:\Program Files\ fails. I usually have CMake install elsewhere by changing the CMAKE_INSTALL_PREFIX John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On 08/26/2010 09:45 AM, John Drescher wrote: On Thu, Aug 26, 2010 at 6:47 AM, Hickel, Kellykelly_hic...@bmc.com wrote: -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Mike McQuaid Sent: Thursday, August 26, 2010 1:12 AM To: Mark Roden Cc: cmake@cmake.org Subject: Re: [CMake] several questions about cmake On 26 August 2010 01:34, Mark Rodenmmro...@gmail.com wrote: I'm starting to get deep into CMake, and I have a few questions as I try to convert the socket++ library such that it can be compiled by CMake on Windows. 1) The default install directory on Windows is C:\Program Files, or C:\Program Files (x86) on 64 bit. This default will not work on Windows 7 (and perhaps Vista), because the user isn't running as administrator anymore, and only administrators can modify that directory. There should probably be a warning to that effect on windows systems; otherwise, there are painful ways to run install, but they are painful. Most developers run as administrator so I don't think there should be a warning. In Windows 7 and Windows 2008 server, being logged in as a user in the Administrators group is not sufficient, you have to elevate the privs of your process to write in those directories. Another possibility is turning off UAC all together. So the warning might still be a good idea. I agree. Installing on these systems even as administrator to the default location C:\Program Files\ fails. I usually have CMake install elsewhere by changing the CMAKE_INSTALL_PREFIX Interesting.. because on Unix systems the default is /usr/local which also requires elevated privileges. Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
1) The default install directory on Windows is C:\Program Files, or
C:\Program Files (x86) on 64 bit. ?This default will not work on
Windows 7 (and perhaps Vista), because the user isn't running as
administrator anymore, and only administrators can modify that
directory. ?There should probably be a warning to that effect on
windows systems; otherwise, there are painful ways to run install, but
they are painful.
Most developers run as administrator so I don't think there should be a
warning.
As a matter of fact, most developers do NOT run as administrator on Win7 and
Vista; default users start with a split security token and you have to elevate
permissions to write to the 'program files' directory. The only way around
this is to turn off UAC; that's an individual decision whether one feels safe
doing that.
I would also like to see the default install directory for cmake change. In
the meantime, I have my cmake script itself change the default:
# On windows, it's convenient to change the default install prefix such that it
does NOT point to 'program files'
if( WIN32 AND CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT )
set( CMAKE_INSTALL_PREFIX ${PROJECT_BINARY_DIR}/install CACHE
PATH Install path prefix, prepended onto install directories FORCE )
endif( )
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] several questions about cmake
On 08/26/2010 05:38 PM, Mark Roden wrote:
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
Just put \ in front of the quotation marks, and the hello world code will
work.
That's not my point. The code I gave has no double quotes in it, and
it still doesn't compile properly, but it does compile and work in a
visual studio environment.
If I do:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
strcpy(buf, \Hello world\n\);
} EXTERN_C)
I get
Performing Test EXTERN_C
Performing Test EXTERN_C - Failed
But that code compiles in an empty vs2008 project.
How can I get the compiler error? I don't see why this code test should
fail.
You need to escape the newline in the string literal four-fold, i.e.
\Hello worldn\. Moreover, void isn't allowed as the return
type of main() in C++, use int instead.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] several questions about cmake
I'm starting to get deep into CMake, and I have a few questions as I
try to convert the socket++ library such that it can be compiled by
CMake on Windows.
1) The default install directory on Windows is C:\Program Files, or
C:\Program Files (x86) on 64 bit. This default will not work on
Windows 7 (and perhaps Vista), because the user isn't running as
administrator anymore, and only administrators can modify that
directory. There should probably be a warning to that effect on
windows systems; otherwise, there are painful ways to run install, but
they are painful.
2) I'm trying to check to see if a certain C++ code chunk will
compile. The line is:
CHECK_CXX_SOURCE_COMPILES(
#include string.h
#include stdio.h
void main(){
char buf[100];
char buf2[100];
strncpy(buf2, buf, 5);
buf2[5] = '\0';
puts(buf2);
} EXTERN_C)
The EXTERN_C test is failing here. The problem is, I can cut and
paste that code into a blank project in vs2008 and it compiles just
fine. Is there a way to see the compiler error, or to determine why
that would fail?
The code in the configure.in file is:
AC_TRY_LINK([
# include string.h
# include stdio.h
], [
char buf[100];
strcpy(buf, Hello world\n);
],
bz_cv_cplusplus_needexternCwrapper=no,
bz_cv_cplusplus_needexternCwrapper=yes)
])
I can't use that directly (or can I?) because the quotation marks in
Hello World prematurely cut off the code in the SOURCE section of
CHECK_CXX_SOURCE_COMPILES, and I get an error that the variable World
makes no sense.
3) There is a check for the presence of the Libg++ library, but no
specific mention of which function is needed. According to what I can
find on CheckLibraryExists, I need to provide a specific function to
determine if that library is present. The code in configure.in is:
AC_CHECK_HEADER(_G_config.h, AC_DEFINE(_S_LIBGXX))
In that case, should I be looking for a particular function in
_G_config.h (which I don't have, since I'm on Windows) and just using
it arbitrarily? I'm not even close to the point where this code can
fail in compilation and therefore determine the error directly.
4) There are two checks for potentially predefined variables, namely
sys_siglist and sys_errlist. The code to check for these looks like:
AC_CACHE_VAL(socketxx_cv_siglist, [
AC_TRY_LINK([
# include unistd.h
# include sys/signal.h
], [
#ifndef _sys_siglist
extern char* _sys_siglist[];
#endif
puts(*_sys_siglist);
],
socketxx_cv_siglist=_sys_siglist,
socketxx_cv_siglist=sys_siglist) ])
AC_DEFINE_UNQUOTED(SYS_SIGLIST, $socketxx_cv_siglist)
Windows doesn't have unistd.h or sys/signal.h, so I know that this
will fail, regardless of the test. I'm unfamiliar with these
variables; does anyone have any insight into them? It looks like if
the code compiles, the variable _sys_siglist will be used, otherwise,
sys_siglist, whatever that is. I'm tempted to just say that it is
what it is, and if other unix users have issues, we can fix the cmake
file then. The typical sloppiness of someone not dealing with their
native platform, I guess :)
There are other problems with converting this file, but I want to
start with this one and still hack away at the others.
Thanks!
Mark
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
