Re: [CMake] Linking problem
On Nov 7, 2007 2:12 AM, Salvatore Iovene <[EMAIL PROTECTED]> wrote: > Hi, > I'm not 100% sure this is really a CMake related question, but I'll > fire it up anyway: > > I'm building a series of static libraries, name them liba.a, libb.a > and libc.a, and linking them into a shared library libfoo.so. > > Then I'm building libx.a liby.a and libz.a and linking them into the > shared libbar.so. > > Then I have an executable whatever.exe that's linked to to libfoo.so > and libbar.so. The linking of the executable fails complaining of > certain missing simbols. Some symbols from liba.a are missing in > libbar.so. I'm not a linking expert, but why should static symbols that you embedded in libfoo.so be visible to libbar.so? > So far I have "fixed" the issue by linking one of the libs of > libfoo.so (say libx.a) to libbar.so. But this smells of nasy > workaround. Why should it be? You're saying you really don't want those underlying static libs to know about each other. If you want symbols from "a" to be visible to everyone, you should be making it a dynamic liba.so. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cvs version 'Segmentation Fault'
> Would it be possible for you to run ctest in gdb or some debugger and > send a call stack of the crash? Here is the stack juste after Ctest crashed (gdb) bt #0 0x00d5175d in std::string::append () from /usr/lib/libstdc++.so.6 #1 0x00d51972 in std::string::operator+= () from /usr/lib/libstdc++.so.6 #2 0x081c5b01 in cmCTestTestHandler::ProcessOneTest () #3 0x081c768e in cmCTestTestHandler::ProcessDirectory () #4 0x081c34fa in cmCTestTestHandler::ProcessHandler () #5 0x081e3fe4 in cmCTestHandlerCommand::InitialPass () #6 0x081b3707 in cmCommand::InvokeInitialPass () #7 0x0822f1f3 in cmMakefile::ExecuteCommand () #8 0x0822ffc3 in cmMakefile::ReadListFile () #9 0x081aefe8 in cmCTestScriptHandler::ReadInScript () #10 0x081afbf9 in cmCTestScriptHandler::RunConfigurationScript () #11 0x081adc3d in cmCTestScriptHandler::ProcessHandler () #12 0x08171fda in cmCTest::Run () #13 0x081620cb in main () Uncannily in gdb the crash appends earlier, not only near the 99th one. This time it was just after the 25th test. If this stack result is not enough I can send you more (if you tell me what) Baptiste ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Nov 7, 2007 2:12 AM, Salvatore Iovene > <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm not 100% sure this is really a CMake related question, but I'll > > fire it up anyway: > > > > I'm building a series of static libraries, name them liba.a, libb.a > > and libc.a, and linking them into a shared library libfoo.so. > > > > Then I'm building libx.a liby.a and libz.a and linking them into the > > shared libbar.so. > > > > Then I have an executable whatever.exe that's linked to to libfoo.so > > and libbar.so. The linking of the executable fails complaining of > > certain missing simbols. Some symbols from liba.a are missing in > > libbar.so. > > I'm not a linking expert, but why should static symbols that you > embedded in libfoo.so be visible to libbar.so? Because libbar uses libfoo. > > So far I have "fixed" the issue by linking one of the libs of > > libfoo.so (say libx.a) to libbar.so. But this smells of nasy > > workaround. > > Why should it be? You're saying you really don't want those > underlying static libs to know about each other. If you want symbols > from "a" to be visible to everyone, you should be making it a dynamic > liba.so. My assumption here is that linking all the static libs liba.a, libb.a and libc.a in libfoo.so, the symbols in liba, libb and libc will be visible from libraries that link against libfoo. Maybe this is the problem? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link directories order
OK, CMake does not know what you are doing here. It is treating LDFLAGS like some linker flag. The idea was something like -64 or some other linker specific flag for a platform. Ok. If you inject directories into the link line, you are sort of out of luck. Why are you doing it this way? What other way could I do it? - There's no official definition of what should be found in LDFLAGS, but most of the software that use LDFLAGS (in particular autotools) expect you to put non-standard link directories in there. - Isn't it the most standard way (in unix) to tell a build system to look for libraries in non-standard places? Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene <[EMAIL PROTECTED]> wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > > On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: > > > On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > >> On Nov 7, 2007 2:12 AM, Salvatore Iovene > >> <[EMAIL PROTECTED]> wrote: > >>> Hi, > >>> I'm not 100% sure this is really a CMake related question, but I'll > >>> fire it up anyway: > >>> > >>> I'm building a series of static libraries, name them liba.a, libb.a > >>> and libc.a, and linking them into a shared library libfoo.so. > >>> > >>> Then I'm building libx.a liby.a and libz.a and linking them into the > >>> shared libbar.so. > >>> > >>> Then I have an executable whatever.exe that's linked to to libfoo.so > >>> and libbar.so. The linking of the executable fails complaining of > >>> certain missing simbols. Some symbols from liba.a are missing in > >>> libbar.so. > > Let's say that there's a symbol S in liba.a, that S is the only symbol > in its object, and that S is not used by libfoo. In Darwin, S will not > be included in libfoo, and the result you get is expectable. I don't > know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > > On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: > > > On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > >> > >> On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: > >> > >>> On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > On Nov 7, 2007 2:12 AM, Salvatore Iovene > <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm not 100% sure this is really a CMake related question, but > > I'll > > fire it up anyway: > > > > I'm building a series of static libraries, name them liba.a, > > libb.a > > and libc.a, and linking them into a shared library libfoo.so. > > > > Then I'm building libx.a liby.a and libz.a and linking them > > into the > > shared libbar.so. > > > > Then I have an executable whatever.exe that's linked to to > > libfoo.so > > and libbar.so. The linking of the executable fails complaining of > > certain missing simbols. Some symbols from liba.a are missing in > > libbar.so. > >> > >> Let's say that there's a symbol S in liba.a, that S is the only > >> symbol > >> in its object, and that S is not used by libfoo. In Darwin, S will > >> not > >> be included in libfoo, and the result you get is expectable. I don't > >> know if this simple explanation translates to Linux. > > > > I don't know either, but that seems to be the case. Any ideas on > > how to fix it? > > IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't > link against liba. > > I think you could do either of > > 1.- make all your static libs dynamic, and link libbar against liba if > libbar uses symbols from liba. > > 2.- link neither libfoo nor libbar to liba, but link whatever.exe to > liba. This will require an extra flag about undefined symbols > under Darwin, but I don't think ld will complain under Linux. > > Option (1) seems far nicer to me. > > Hope this helps. > Renaud. Thanks. Your options seem very reasonable. The thing is, though, that the various liba, libb, libc were meant to be only used to build a bigger library called libfoo. So what I really want is that symbols in liba are defined in libfoo even if libfoo doesn't use them. Does it make sense? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 11:35, Salvatore Iovene wrote: On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene <[EMAIL PROTECTED]> wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. Thanks. Your options seem very reasonable. The thing is, though, that the various liba, libb, libc were meant to be only used to build a bigger library called libfoo. Then why don't you build all objects from foo, a, b, c to be PIC and pack them all together in foo? Or if you really want intermediate archives, maybe you can build the objects of a, b, c to be PIC, archive them in .a archives, and use ld to put them together. But this is not the same thing as linking foo to a, b, c using gcc and -la -lb -lc, which means to only fetch needed symbols. The bottom line is, what you mean to do is probably not very common, and I don't think there will be a high-level CMake primitive that will do that for you. This is just my opinion though :-) Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On Nov 7, 2007 2:12 AM, Salvatore Iovene <[EMAIL PROTECTED]> wrote: Hi, I'm not 100% sure this is really a CMake related question, but I'll fire it up anyway: I'm building a series of static libraries, name them liba.a, libb.a and libc.a, and linking them into a shared library libfoo.so. Then I'm building libx.a liby.a and libz.a and linking them into the shared libbar.so. Then I have an executable whatever.exe that's linked to to libfoo.so and libbar.so. The linking of the executable fails complaining of certain missing simbols. Some symbols from liba.a are missing in libbar.so. Let's say that there's a symbol S in liba.a, that S is the only symbol in its object, and that S is not used by libfoo. In Darwin, S will not be included in libfoo, and the result you get is expectable. I don't know if this simple explanation translates to Linux. I don't know either, but that seems to be the case. Any ideas on how to fix it? IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't link against liba. I think you could do either of 1.- make all your static libs dynamic, and link libbar against liba if libbar uses symbols from liba. 2.- link neither libfoo nor libbar to liba, but link whatever.exe to liba. This will require an extra flag about undefined symbols under Darwin, but I don't think ld will complain under Linux. Option (1) seems far nicer to me. Hope this helps. Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > > On 07 Nov 2007, at 11:35, Salvatore Iovene wrote: > > > On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > >> > >> On 07 Nov 2007, at 11:04, Salvatore Iovene wrote: > >> > >>> On 11/7/07, Renaud Detry <[EMAIL PROTECTED]> wrote: > > On 07 Nov 2007, at 09:59, Salvatore Iovene wrote: > > > On 11/7/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > >> On Nov 7, 2007 2:12 AM, Salvatore Iovene > >> <[EMAIL PROTECTED]> wrote: > >>> Hi, > >>> I'm not 100% sure this is really a CMake related question, but > >>> I'll > >>> fire it up anyway: > >>> > >>> I'm building a series of static libraries, name them liba.a, > >>> libb.a > >>> and libc.a, and linking them into a shared library libfoo.so. > >>> > >>> Then I'm building libx.a liby.a and libz.a and linking them > >>> into the > >>> shared libbar.so. > >>> > >>> Then I have an executable whatever.exe that's linked to to > >>> libfoo.so > >>> and libbar.so. The linking of the executable fails > >>> complaining of > >>> certain missing simbols. Some symbols from liba.a are missing in > >>> libbar.so. > > Let's say that there's a symbol S in liba.a, that S is the only > symbol > in its object, and that S is not used by libfoo. In Darwin, S will > not > be included in libfoo, and the result you get is expectable. I > don't > know if this simple explanation translates to Linux. > >>> > >>> I don't know either, but that seems to be the case. Any ideas on > >>> how to fix it? > >> > >> IMHO, you shouldn't use symbols from liba in libbar if libbar doesn't > >> link against liba. > >> > >> I think you could do either of > >> > >> 1.- make all your static libs dynamic, and link libbar against > >> liba if > >> libbar uses symbols from liba. > >> > >> 2.- link neither libfoo nor libbar to liba, but link whatever.exe to > >> liba. This will require an extra flag about undefined symbols > >> under Darwin, but I don't think ld will complain under Linux. > >> > >> Option (1) seems far nicer to me. > >> > >> Hope this helps. > >> Renaud. > > > > Thanks. Your options seem very reasonable. The thing is, though, that > > the various liba, libb, libc were meant to be only used to build a > > bigger library called libfoo. > > Then why don't you build all objects from foo, a, b, c to be PIC and > pack them all together in foo? Or if you really want intermediate > archives, maybe you can build the objects of a, b, c to be PIC, > archive them in .a archives, and use ld to put them together. But this > is not the same thing as linking foo to a, b, c using gcc and -la -lb > -lc, which means to only fetch needed symbols. > > The bottom line is, what you mean to do is probably not very common, > and I don't think there will be a high-level CMake primitive that will > do that for you. > > This is just my opinion though :-) What do you mean by PIC? Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > Quoting Salvatore Iovene <[EMAIL PROTECTED]>: > > On 11/7/07, Salvatore Iovene <[EMAIL PROTECTED]> wrote: > > > >> What do you mean by PIC? > >> Thanks! > > > > Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have > > to try it on Windows tho. I hope it's good as a solution and not just > > a hack! :) > > Windows DLLs work differently. > > When putting code into shared object under Linux, they _must_ be > compiled as PIC. Back to your problem: GNU ld has an option to > forcibly include all symbols during linking instead of only the used > ones, take a look at its manpage. Thanks f or your answer. I checked ld man page and I think you refer to the --export-dynamic option. Building my libs with -fPIC seemed to fix the problem on Linux, so do I really need that ld option? -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 11/7/07, Salvatore Iovene <[EMAIL PROTECTED]> wrote: > What do you mean by PIC? > Thanks! Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have to try it on Windows tho. I hope it's good as a solution and not just a hack! :) -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] -pipe, -g and -fPIC on WIN32
Hi list,
I'm doing the following:
CHECK_CXX_COMPILER_FLAG("-fPIC" HAVE_FPIC_FLAG)
IF(HAVE_FPIC_FLAG)
SET(${CMAKE_CXX_FLAGS} "${CMAKE_CXX_FLAGS} -fPIC")
ENDIF(HAVE_FPIC_FLAG)
And the same with -pipe and -g.
This works fine in Linux, but when trying on WIN32 with Visual Studio
command line prompt, I get that the check for the flag succedes, but
then the compiler options are actually -pipe -g -fPIC and the compiler
issues a warning about ignoring those unknown options.
What is the right way of doing this?
Thanks!
--
Salvatore Iovene
http://www.iovene.com/
Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Quoting Salvatore Iovene <[EMAIL PROTECTED]>: On 11/7/07, Salvatore Iovene <[EMAIL PROTECTED]> wrote: What do you mean by PIC? Thanks! Oh, -fPIC. I figured it out. Seems to work fine on Linux. I still have to try it on Windows tho. I hope it's good as a solution and not just a hack! :) Windows DLLs work differently. When putting code into shared object under Linux, they _must_ be compiled as PIC. Back to your problem: GNU ld has an option to forcibly include all symbols during linking instead of only the used ones, take a look at its manpage. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import libraries prefix bug under windows?
Hey Brandon...
You will find the stuff in attachment.
Cheers,
Ronan.
Brandon Van Every wrote:
Please provide a reproducer script so others of us can test your claim.
Cheers,
Brandon Van Every
On Nov 6, 2007 6:04 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote:
Hi,
I have been using CMake for quite a while now under
Linux/MacOSX/Cygwin for a large project.
Recently I have been trying to make it work under Windows, using the
freely available to download Windows SDK. (cmake -G "NMake Makefiles")
I encountered a small problem, which might be a CMake bug. (I am using
the latest cmake 2.4.7)
I ask CMake to produce a dll (let say foo.dll), and then I want to link
this dll to produce an executable bar.exe.
I also changed the prefixes of the dll using:
SET(CMAKE_SHARED_LIBRARY_PREFIX "lib")
SET(CMAKE_IMPORT_LIBRARY_PREFIX "lib")
So in fact, the dll generated is libfoo.dll (which is right). An import
library is also generated (libfoo.lib) (which is still right).
But then when the makefile generated by CMake wants to link and produce
bar.exe, the linker complains that it did not find "foo.lib". It seems
it completely ignore the given prefix of the dll here.
Moving "libfoo.lib" to "foo.lib" and resuming the compilation works.
Not having a prefix also works.
So I would say it is a bug.
In fact, I am not sure at all of this CMAKE_IMPORT_LIBRARY_PREFIX:
whatever I put there is ignored for the production of libfoo.lib (it is
always libfoo.lib which is produced, according to what it is given by
CMAKE_SHARED_LIBRARY_PREFIX)
Ronan.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
extern foo();
int main()
{
foo();
return 0;
}
# Works perfectly under Cygwin,Linux,MacOSX
# Sux under Windows (cmake -G "NMake Makefiles" followed by nmake)
# If you comment these 3 lines, it works
# If after the generation of libfoo.lib you rename it in foo.lib and do nmake
again, it works
SET(CMAKE_SHARED_LIBRARY_PREFIX "lib")
SET(CMAKE_STATIC_LIBRARY_PREFIX "lib")
SET(CMAKE_IMPORT_LIBRARY_PREFIX "lib") # seems useless
# Shared library foo
ADD_LIBRARY(foo SHARED foo.c)
# Executable bar
ADD_EXECUTABLE(bar bar.c)
TARGET_LINK_LIBRARIES(bar foo)
#include
#ifdef _WIN32
#define FOO_API __declspec(dllexport)
#else
#define FOO_API
#endif
FOO_API void foo()
{
printf("amazingly working\n");
}
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ignoring a specific library
Hi Philip,
Thanks for your help. I down-graded to 2.4.6 but no luck. Here's my exact text:
SET(VS_MULTITHREADED_DEBUG_IGNORE_LIBRARY_FLAGS
"/NODEFAULTLIB:nafxcwd.lib
/NODEFAULTLIB:libcmtd.lib"
)
SET_TARGET_PROPERTIES(my_test_app PROPERTIES
LINK_FLAGS_DEBUG
${VS_MULTITHREADED_DEBUG_IGNORE_LIBRARY_FLAGS})
After creating the solution files, I don't see anything in the ignore
default library fields - any ideas?
Thanks,
Mark
On 11/2/07, Philip Lowman <[EMAIL PROTECTED]> wrote:
> Mark Wyszomierski wrote:
> > Is it possible to add an ignore library to CMakeLists.txt? This is
> > specifically for a win32 project. I want to ignore:
> >
> > nafxcwd.lib
> > libcmtd.lib
>
> Here's how I do this with CMake 2.4.6. Unfortunately passing more than
> one /NODEFAULTLIB arguments was broken in CMake 2.4.7 (see Bug #5455).
>
> In short, use the SET_TARGET_PROPERTIES() with the LINK_FLAGS or
> LINK_FLAGS_DEBUG, LINK_FLAGS_RELEASE, etc. options.
>
>
> SET(VS_MULTITHREADED_DEBUG_DLL_IGNORE_LIBRARY_FLAGS
>"/NODEFAULTLIB:libc.lib
> /NODEFAULTLIB:libcmt.lib
> /NODEFAULTLIB:msvcrt.lib
> /NODEFAULTLIB:libcd.lib
> /NODEFAULTLIB:libcmtd.lib"
> )
> SET(VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS
>"/NODEFAULTLIB:libc.lib
> /NODEFAULTLIB:libcmt.lib
> /NODEFAULTLIB:libcd.lib
> /NODEFAULTLIB:libcmtd.lib
> /NODEFAULTLIB:msvcrtd.lib"
> )
>
> IF(MSVC)
> SET_TARGET_PROPERTIES(simulator-static PROPERTIES
>LINK_FLAGS_DEBUG
>${VS_MULTITHREADED_DEBUG_DLL_IGNORE_LIBRARY_FLAGS})
>
> SET_TARGET_PROPERTIES(simulator-static PROPERTIES
> LINK_FLAGS_RELWITHDEBINFO
> ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
> SET_TARGET_PROPERTIES(simulator-static PROPERTIES
> LINK_FLAGS_RELEASE
> ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
> SET_TARGET_PROPERTIES(simulator-static PROPERTIES
> LINK_FLAGS_MINSIZEREL
> ${VS_MULTITHREADED_RELEASE_DLL_IGNORE_LIBRARY_FLAGS})
> ENDIF(MSVC)
>
>
> --
> Philip Lowman
> Sr. Simulation Development Engineer, Modeling and Simulation Technology
> General Dynamics Land Systems
> http://www.gdls.com
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import libraries prefix bug under windows?
On Nov 6, 2007 6:04 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote: > > I also changed the prefixes of the dll using: > SET(CMAKE_SHARED_LIBRARY_PREFIX "lib") > SET(CMAKE_IMPORT_LIBRARY_PREFIX "lib") I've never used this mechanism to set library prefixes. I have always used SET_TARGET_PROPERTIES, using the PREFIX, SUFFIX, IMPORT_PREFIX, and IMPORT_SUFFIX properties. Where is it documented that you're supposed to be able to affect the output by SETting global variables? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import libraries prefix bug under windows?
Yes, indeed, it does work with SET_TARGET_PROPERTIES. CMAKE_SHARED_LIBRARY_PREFIX advantage is that it set up the prefix for all libraries. So no need each time you have a library target to have this SET_TARGET_PROPERTIES additional line. Like that, I do not remember where I saw doc about it. It is actually referenced (without any comments) on the CMake Useful Variables page: http://www.cmake.org/Wiki/CMake_Useful_Variables Also, if you look at the code of CMake in Modules/Platform/*.cmake it is used in a lot of scripts to initialize the default prefixes (including Windows!). Cheers, Ronan. Brandon Van Every wrote: On Nov 6, 2007 6:04 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote: I also changed the prefixes of the dll using: SET(CMAKE_SHARED_LIBRARY_PREFIX "lib") SET(CMAKE_IMPORT_LIBRARY_PREFIX "lib") I've never used this mechanism to set library prefixes. I have always used SET_TARGET_PROPERTIES, using the PREFIX, SUFFIX, IMPORT_PREFIX, and IMPORT_SUFFIX properties. Where is it documented that you're supposed to be able to affect the output by SETting global variables? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On Nov 7, 2007 11:08 AM, KSpam <[EMAIL PROTECTED]> wrote: > > Static linking is a strange beast. When you link in a static library, it will > only resolve symbols that are currently being used. All other symbols from > the static library are pruned out. The nice thing is that this reduces the > binary object size. On the other hand, symbols that may be needed further > down the chain are not resolved, as you have found out. I don't see why people think this is "strange." Granted, the word "static" is overloaded in C parlance, but generally it means the scope of the data is hidden. If you put static stuff into a dynamic library, the only intent is to make all the dynamic functions work and export properly. It's not to reveal all your underlying static gunk + the dynamic functions. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Hello, There a much nicer platform independent writeup on this at: http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 There may be a couple of syntactical issues with the writeup. For example, you may need to have at least one source file composing the shared library, in addition to the static libraries that you want to ad. The "-fPIC" should be set in SET_TARGET_PROPERTIES and not in ADD_LIBRARY. I believe the example I have below to be correct, but your mileage may vary. Regards, Juan Juan Sanchez wrote: > Two things with convenience libraries. Part of this may be in the FAQ: > > On linux, compile the code fPIC or fpic (slightly different meanings). > > So for library hello: > SET_TARGET_PROPERTIES( > hello PROPERTIES > OUTPUT_NAME hello > CLEAN_DIRECT_OUTPUT 1 > COMPILE_FLAGS -fPIC > ) > > where hello is the name of your static convenience library. > > Make sure all symbols get put into the so: > target_link_libraries(mywrap -Wl,-whole-archive > hello -Wl,-no-whole-archive) > > where mywrap is the name of the shared library, and hello is the static > library you want attached to it. If you are attaching multiple > libraries, linker order may be important. > > Juan > > > > Salvatore Iovene wrote: >> Hi, >> I'm not 100% sure this is really a CMake related question, but I'll >> fire it up anyway: >> >> I'm building a series of static libraries, name them liba.a, libb.a >> and libc.a, and linking them into a shared library libfoo.so. >> >> Then I'm building libx.a liby.a and libz.a and linking them into the >> shared libbar.so. >> >> Then I have an executable whatever.exe that's linked to to libfoo.so >> and libbar.so. The linking of the executable fails complaining of >> certain missing simbols. Some symbols from liba.a are missing in >> libbar.so. >> >> So far I have "fixed" the issue by linking one of the libs of >> libfoo.so (say libx.a) to libbar.so. But this smells of nasy >> workaround. >> >> Obviously I'm doing something wrong here, so could anyone please help? >> >> Thanks! >> > > -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Two things with convenience libraries. Part of this may be in the FAQ: On linux, compile the code fPIC or fpic (slightly different meanings). So for library hello: SET_TARGET_PROPERTIES( hello PROPERTIES OUTPUT_NAME hello CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) where hello is the name of your static convenience library. Make sure all symbols get put into the so: target_link_libraries(mywrap -Wl,-whole-archive hello -Wl,-no-whole-archive) where mywrap is the name of the shared library, and hello is the static library you want attached to it. If you are attaching multiple libraries, linker order may be important. Juan Salvatore Iovene wrote: > Hi, > I'm not 100% sure this is really a CMake related question, but I'll > fire it up anyway: > > I'm building a series of static libraries, name them liba.a, libb.a > and libc.a, and linking them into a shared library libfoo.so. > > Then I'm building libx.a liby.a and libz.a and linking them into the > shared libbar.so. > > Then I have an executable whatever.exe that's linked to to libfoo.so > and libbar.so. The linking of the executable fails complaining of > certain missing simbols. Some symbols from liba.a are missing in > libbar.so. > > So far I have "fixed" the issue by linking one of the libs of > libfoo.so (say libx.a) to libbar.so. But this smells of nasy > workaround. > > Obviously I'm doing something wrong here, so could anyone please help? > > Thanks! > -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link directories order
Renaud Detry wrote: OK, CMake does not know what you are doing here. It is treating LDFLAGS like some linker flag. The idea was something like -64 or some other linker specific flag for a platform. Ok. If you inject directories into the link line, you are sort of out of luck. Why are you doing it this way? What other way could I do it? - There's no official definition of what should be found in LDFLAGS, but most of the software that use LDFLAGS (in particular autotools) expect you to put non-standard link directories in there. You should be using FIND_LIBRARY to find the things you want to link in, or at least finding the directory with a FIND_FILE, and then using LINK_DIRECTORIES. LDFLAGS is a bad idea because your users will also have to set this to get it to work. - Isn't it the most standard way (in unix) to tell a build system to look for libraries in non-standard places? With CMake you should be telling CMake which libraries you want to use. I suppose we could attempt to parse the LDFLAGS variable. Feel free to make a feature request, but it won't work for any version of CMake currently out. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
Salvatore, It sounds like your static libraries were meant strictly as "convenience" libraries (i.e. libraries that are only used internal to the build system to make building other libraries easier). In CMake, it is much easier to not use convenience libraries. Instead, just add all of the sources from the static libraries into the appropriate shared library source list. In other words skip the middle man. Static linking is a strange beast. When you link in a static library, it will only resolve symbols that are currently being used. All other symbols from the static library are pruned out. The nice thing is that this reduces the binary object size. On the other hand, symbols that may be needed further down the chain are not resolved, as you have found out. Justin ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] INCLUDE: Dart or Ctest
Hello all, I intend to start to send my tests to a Dart server. My very first problem is to figure what's the difference between INCLUDE(Dart) and INCLUDE(CTest). I have my tests working, but I just used ENABLE_TESTS() until now. Thanks in advance, -- Vitor VASCONCELOS Projet QGAR LORIA / INRIA-Lorraine Campus Scientifique, BP 239 54506, Vandoeuvre-lès-Nancy, FRANCE Tel: +33 (0)3 54 95 85 76 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cvs version 'Segmentation Fault'
Baptiste Derongs wrote: Would it be possible for you to run ctest in gdb or some debugger and send a call stack of the crash? Here is the stack juste after Ctest crashed (gdb) bt #0 0x00d5175d in std::string::append () from /usr/lib/libstdc++.so.6 #1 0x00d51972 in std::string::operator+= () from /usr/lib/libstdc++.so.6 #2 0x081c5b01 in cmCTestTestHandler::ProcessOneTest () #3 0x081c768e in cmCTestTestHandler::ProcessDirectory () #4 0x081c34fa in cmCTestTestHandler::ProcessHandler () #5 0x081e3fe4 in cmCTestHandlerCommand::InitialPass () #6 0x081b3707 in cmCommand::InvokeInitialPass () #7 0x0822f1f3 in cmMakefile::ExecuteCommand () #8 0x0822ffc3 in cmMakefile::ReadListFile () #9 0x081aefe8 in cmCTestScriptHandler::ReadInScript () #10 0x081afbf9 in cmCTestScriptHandler::RunConfigurationScript () #11 0x081adc3d in cmCTestScriptHandler::ProcessHandler () #12 0x08171fda in cmCTest::Run () #13 0x081620cb in main () Uncannily in gdb the crash appends earlier, not only near the 99th one. This time it was just after the 25th test. If this stack result is not enough I can send you more (if you tell me what) If you could build cmake with Debug (-g) it would be more helpful... Also, if you add -VV to ctest what are the last 100 lines of output? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] tool flags
Another stupid newbie question --
How does one set/change the compiler and linker flags variables?
Putting things like
STRING(REPLACE /MD /MT CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE})
or even
SET( CMAKE_EXE_LINKER_FLAGS
${CMAKE_EXE_LINKER_FLAGS} /noDefaultLib:MSVCRT /noDefaultLib:MSVCRTd
CACHE STRING "for MSVC"
)
in the root cmakelists.txt has no effect.
Of course the answer must be obvious, but I can't find it.
Thanks. Tom
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem with Qt4 and release mode on windows
Hi, when I compile a qt plugin in release mode (and therefore link against release qt lib) I've the problem that cmake does not set -DQT_NO_DEBUG . Because of this Qt assumes we're compiling this plugin in debug mode: qconfig.h: == #if !defined(QT_NO_DEBUG) && !defined(QT_DEBUG) # define QT_DEBUG #endif which leads to the wrong Q_PLUGIN_VERIFICATION_DATA: qplugin.h: == # ifdef QT_NO_DEBUG #define QPLUGIN_DEBUG_STR "false" # else #define QPLUGIN_DEBUG_STR "true" # endif # define Q_PLUGIN_VERIFICATION_DATA \ static const char *qt_plugin_verification_data = \ "pattern=""QT_PLUGIN_VERIFICATION_DATA""\n" \ "version="QT_VERSION_STR"\n" \ "debug="QPLUGIN_DEBUG_STR"\n" \ "buildkey="QT_BUILD_KEY"\0"; --> an app does not load this plugin because the verification data does not match. I'm posting this to cmake and kde-buildsystem list because I don't know who to blame here - qt because it's not recognizing the NDEBUG flag (which seems to be a widely used flag) or cmake because it's not adding QT_NO_DEBUG to the compiler flags. Christian signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] changing object file extension from ".o"
On Wednesday 07 November 2007, Matthew McCormick wrote: > Hi, > > Having difficulty changing the object file extension. In my > CMakeLists.txtI have > > SET(CMAKE_C_OUTPUT_EXTENSION ".obj") > SET(CMAKE_CXX_OUTPUT_EXTENSION ".obj") > > but I still get *.o object files. Yes, that's too late in the cmake language setup process. What do you need that for ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -pipe, -g and -fPIC on WIN32
On Nov 7, 2007 6:35 AM, Salvatore Iovene
<[EMAIL PROTECTED]> wrote:
> Hi list,
> I'm doing the following:
>
> CHECK_CXX_COMPILER_FLAG("-fPIC" HAVE_FPIC_FLAG)
>
> IF(HAVE_FPIC_FLAG)
> SET(${CMAKE_CXX_FLAGS} "${CMAKE_CXX_FLAGS} -fPIC")
> ENDIF(HAVE_FPIC_FLAG)
>
> And the same with -pipe and -g.
>
> This works fine in Linux, but when trying on WIN32 with Visual Studio
> command line prompt, I get that the check for the flag succedes, but
> then the compiler options are actually -pipe -g -fPIC and the compiler
> issues a warning about ignoring those unknown options.
>
> What is the right way of doing this?
> Thanks!
I say it's bugged. CheckCCompilerFlag.cmake is passing your flag in
CMAKE_REQUIRED_DEFINITIONS. It should be passing it in
CMAKE_REQUIRED_FLAGS. CHECK_C_COMPILER_FLAG calls
CHECK_C_SOURCE_COMPILES, which ultimately invokes a TRY_COMPILE. Your
flag should be passed to CMAKE_FLAGS and it isn't. The only other
possibility I see is that all the docs are wrong when they say that
COMPILE_DEFINITIONS is for -D flags.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] changing object file extension from ".o"
Hi, Having difficulty changing the object file extension. In my CMakeLists.txtI have SET(CMAKE_C_OUTPUT_EXTENSION ".obj") SET(CMAKE_CXX_OUTPUT_EXTENSION ".obj") but I still get *.o object files. I am working with cmake version 2.4-patch 7 on Cygwin. Thanks. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import libraries prefix bug under windows?
On Nov 7, 2007 2:09 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote: > Yes, indeed, it does work with SET_TARGET_PROPERTIES. > > CMAKE_SHARED_LIBRARY_PREFIX advantage is that it set up the prefix for > all libraries. So no need each time you have a library target to have > this SET_TARGET_PROPERTIES additional line. > > Like that, I do not remember where I saw doc about it. It is actually > referenced (without any comments) on the CMake Useful Variables page: > http://www.cmake.org/Wiki/CMake_Useful_Variables > > Also, if you look at the code of CMake in Modules/Platform/*.cmake it is > used in a lot of scripts to initialize the default prefixes (including > Windows!). Use as an initializer does not imply that it's an interface for the user to change the value. There's a fair number of CMake "useful" variables that are actually pretty darned useless if you try to write to them. The good news is that in CMake 2.6.0 all the public variables are going to be documented, so perhaps this "read only" confusion will go away. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Import libraries prefix bug under windows?
ok thanks -- well, the variable works fine on all system i tried except windows. i have a workaround, just wanted to mention the problem. even under windows, it recognizes it, as it creates "libfoo.dll" and "libfoo.lib". it is only when linking, that somebody forgot about these prefixes: it tries to find "foo.lib" instead of "libfoo.lib". as all the other systems have a consistent behavior, i considered that as a bug, but, who knows, as you say. ronan. Brandon Van Every wrote: On Nov 7, 2007 2:09 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote: Yes, indeed, it does work with SET_TARGET_PROPERTIES. CMAKE_SHARED_LIBRARY_PREFIX advantage is that it set up the prefix for all libraries. So no need each time you have a library target to have this SET_TARGET_PROPERTIES additional line. Like that, I do not remember where I saw doc about it. It is actually referenced (without any comments) on the CMake Useful Variables page: http://www.cmake.org/Wiki/CMake_Useful_Variables Also, if you look at the code of CMake in Modules/Platform/*.cmake it is used in a lot of scripts to initialize the default prefixes (including Windows!). Use as an initializer does not imply that it's an interface for the user to change the value. There's a fair number of CMake "useful" variables that are actually pretty darned useless if you try to write to them. The good news is that in CMake 2.6.0 all the public variables are going to be documented, so perhaps this "read only" confusion will go away. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
I believe this to be the more accurate than the FAQ and my previous example. In addition, the static and shared libraries can have the same name. Note that cat.cc is an empty file, since the linker will not work without at least one object file on the dynamic target. IF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC) ADD_LIBRARY(zzSTATIC STATIC dog.cc) ADD_LIBRARY(zzDYNAMIC SHARED cat.cc) TARGET_LINK_LIBRARIES(zzDYNAMIC -Wl,-whole-archive zzSTATIC -Wl,-no-whole-archive) SET_TARGET_PROPERTIES( zzSTATIC PROPERTIES OUTPUT_NAME zz CLEAN_DIRECT_OUTPUT 1 COMPILE_FLAGS -fPIC ) SET_TARGET_PROPERTIES( zzDYNAMIC PROPERTIES OUTPUT_NAME zz CLEAN_DIRECT_OUTPUT 1 ) ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC) Regards, Juan Juan Sanchez wrote: > Hello, > > There a much nicer platform independent writeup on this at: > > http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 > > There may be a couple of syntactical issues with the writeup. > > For example, you may need to have at least one source file composing the > shared library, in addition to the static libraries that you want to ad. > > The "-fPIC" should be set in SET_TARGET_PROPERTIES and not in > ADD_LIBRARY. I believe the example I have below to be correct, but your > mileage may vary. > > Regards, > > Juan > > Juan Sanchez wrote: >> Two things with convenience libraries. Part of this may be in the FAQ: >> >> On linux, compile the code fPIC or fpic (slightly different meanings). >> >> So for library hello: >> SET_TARGET_PROPERTIES( >> hello PROPERTIES >> OUTPUT_NAME hello >> CLEAN_DIRECT_OUTPUT 1 >> COMPILE_FLAGS -fPIC >> ) >> >> where hello is the name of your static convenience library. >> >> Make sure all symbols get put into the so: >> target_link_libraries(mywrap -Wl,-whole-archive >> hello -Wl,-no-whole-archive) >> >> where mywrap is the name of the shared library, and hello is the static >> library you want attached to it. If you are attaching multiple >> libraries, linker order may be important. >> >> Juan >> >> >> >> Salvatore Iovene wrote: >>> Hi, >>> I'm not 100% sure this is really a CMake related question, but I'll >>> fire it up anyway: >>> >>> I'm building a series of static libraries, name them liba.a, libb.a >>> and libc.a, and linking them into a shared library libfoo.so. >>> >>> Then I'm building libx.a liby.a and libz.a and linking them into the >>> shared libbar.so. >>> >>> Then I have an executable whatever.exe that's linked to to libfoo.so >>> and libbar.so. The linking of the executable fails complaining of >>> certain missing simbols. Some symbols from liba.a are missing in >>> libbar.so. >>> >>> So far I have "fixed" the issue by linking one of the libs of >>> libfoo.so (say libx.a) to libbar.so. But this smells of nasy >>> workaround. >>> >>> Obviously I'm doing something wrong here, so could anyone please help? >>> >>> Thanks! >>> >> > > -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Choosing between debug and release variants of third-party libraries
I'm sure this is a FAQ, but I cannot find the answer anywhere. Using VS 2003, given that I have a third-party library with debug and release variants: /path/to/lib/release/lib.lib /path/to/lib/debug/lib.lib how do I get CMake to link with the correct variant? Using an absolute path in TARGET_LINK_LIBRARIES() does not work, and I cannot use CMAKE_BUILD_TYPE at configure time. -Torsten This e-mail and any files sent with it contain information that may be privileged or confidential and is the property of the GateHouse Group. This information is intended solely for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use the message or any part thereof. If you have received this e-mail in error, please notify the sender immediately, and delete all copies of this message. In accordance with GateHouse Security Policy, e-mails sent or received may be monitored. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: Re: changing object file extension from ".o"
> > > > Hi, > > > > Having difficulty changing the object file extension. In my > > CMakeLists.txtI have > > > > SET(CMAKE_C_OUTPUT_EXTENSION ".obj") > > SET(CMAKE_CXX_OUTPUT_EXTENSION ".obj") > > > > but I still get *.o object files. > > Yes, that's too late in the cmake language setup process. What do you need > that for ? > > Alex > > I'm trying to work with a compiler where you cannot specify the object extension, the Matlab mex (pseudo) compiler. I tried this, $ CMAKE_C_OUTPUT_EXTENSION=".obj" CMAKE_CXX_OUTPUT_EXTENSION=".obj" ccmake ../convert_visualsonics_2_mat_src/ but it didn't work. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RE: Re: changing object file extension from ".o"
On Wednesday 07 November 2007, Matthew McCormick wrote: > > > Hi, > > > > > > Having difficulty changing the object file extension. In my > > > CMakeLists.txtI have > > > > > > SET(CMAKE_C_OUTPUT_EXTENSION ".obj") > > > SET(CMAKE_CXX_OUTPUT_EXTENSION ".obj") > > > > > > but I still get *.o object files. > > > > Yes, that's too late in the cmake language setup process. What do you > > need that for ? > > > > Alex > > I'm trying to work with a compiler where you cannot specify the object > extension, the Matlab mex (pseudo) compiler. > I tried this, > > $ CMAKE_C_OUTPUT_EXTENSION=".obj" CMAKE_CXX_OUTPUT_EXTENSION=".obj" ccmake > ../convert_visualsonics_2_mat_src/ > > but it didn't work. Yes, this doesn't work. I know that Matlab has this mex compiler what does it exactly do ? Maybe you need to add a file to cmake so it can handle this compiler. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Jesper Eskilson wrote: KSpam wrote: If you run the ZERO_CHECK target, CMake will generate the new project files without building everything. Following ZERO_CHECK, Visual Studio would have to reload the projects, and then you could build like normal. This makes building in Visual Studio essentially a two-step process. Good to know. I'll relay this to my users; I think many of them use a rather convoluted way of running CMake outside of Visual Studio. So, I did look at how to fix this some. I have a c# program that can force a running visual studio process to close and reload the solution it has. The idea would be to have cmake run this when cmake is run as part of the build. However, visual studio has a neat trick of killing all processes launched as part of a build. So, what happens is the reload c# program closes the solution, and VS kills it before it can reload the project. The only way around this is to run some sort of cmake IDE VS reload server, that cmake can contact and ask it to force a reload. Does this sound worth while? It could also unload/load, and build. However, I am not sure we want to restart the build. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] dangerous regex in CHECK_C_SOURCE_COMPILES
It begins with:
MACRO(CHECK_C_SOURCE_COMPILES SOURCE VAR)
IF("${VAR}" MATCHES "^${VAR}$")
What is the intent here? If ${VAR} contains regex special characters
you're going to get all kinds of weird and nasty behavior.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RE: Re: changing object file extension from ".o"
Am Mittwoch 07 November 2007 22:13:32 schrieb Matthew McCormick: > > I'm trying to work with a compiler where you cannot specify the object > extension, the Matlab mex (pseudo) compiler. > I tried this, > > $ CMAKE_C_OUTPUT_EXTENSION=".obj" CMAKE_CXX_OUTPUT_EXTENSION=".obj" ccmake > ../convert_visualsonics_2_mat_src/ > > but it didn't work. I'm coded a bunch of result file parsers (using spirit/spirit2) and connected them to Matlab via mex files (*.mexw32 at windows). The mex frontend is IMHO a very handy thing for very simple cases where the an algorithm is contained in one sourcefile without any external dependencies. I never really used it, because I never had this simple cases ;) I'm using mingw(sometimes msvc) and CMake for this and I can post an simple example if you want me to. Its a little tricky, since there are name clashes between the libs in Matlab's library-dir and gcc's own libs (i.e libm). My access to Matlab is limited to Windows, so I can't provide a general solution. Regards, Maik Beckmann ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 2007-11-07 11:55-0500 Brandon Van Every wrote: On Nov 7, 2007 11:08 AM, KSpam <[EMAIL PROTECTED]> wrote: Static linking is a strange beast. When you link in a static library, it will only resolve symbols that are currently being used. All other symbols from the static library are pruned out. The nice thing is that this reduces the binary object size. On the other hand, symbols that may be needed further down the chain are not resolved, as you have found out. I don't see why people think this is "strange." Granted, the word "static" is overloaded in C parlance, but generally it means the scope of the data is hidden. If you put static stuff into a dynamic library, the only intent is to make all the dynamic functions work and export properly. It's not to reveal all your underlying static gunk + the dynamic functions. I agree "static" has overloaded meanings depending on context, but I don't agree with your interpreation of the meaning of "static" in the case of Unix libraries. (I have no clue about the windows linking case so my remarks below may only apply to the Unix case.) Let's take the simple case of one main programme linked to one library. If the library is static, then linking simply creates an executable consisting of the main routine and copies of the subset of routines that it directly or indirectly uses from the library. The result is a large, completely independent executable. The shared library case is quite different. The linking produces a small incomplete executable consisting of just the main routine plus some minimal extra information to allow the run-time loader to do its job. That executable is essentially completed at run time by the run-time loader which uses routines from the shared library as required to resolve the symbols in the main routine. Thus, the shared library code that is actually used at run time depends on what exists at run time in the library and not what existed in say a previous version of the library at link time. The practical advantage of the static libraries case is simplicity. The practical advantage of the shared libraries case is it is a more flexible linking system which allows fixing bugs in libraries without having to recompile or relink executables. For CMake (and all other build systems I am aware of), the user has a choice of making static libraries or shared libraries from exactly the same library source code. There is no intention to hide the scope of the symbols or anything like that since it is exactly the same library source code in both cases. For more complicated cases of say when you are linking a shared library with a static library, just like the simpler case above the static library code subset that the shared library uses becomes part of the shared library (which is why the -fPIC compile option must be used for the static library code for this case). For real world cases where you have a large collection of interdependent libraries being built for some software project that also depend on external libraries, there are some KISS rules I follow that greatly simplify linking issues. (1) No circular dependencies allowed. (2) For every library that is linked, all symbols in that library must be resolved by explicitly mentioning all libraries at link time that supply the required symbol definitions. I enforce that rule in the Linux case by periodically testing every library that I create with CMake using the "ldd -r" command. (3) Note, the above two rules are all you really need for the shared libraries case (which is my principal development focus). However, if you have external libraries that are static or if you choose static libraries for the libraries you are building internally with CMake, then a third rule is the static libraries a given executable or library depends upon must be listed in the correct order when linking. If, for example, you are linking an executable which depends on static libraries libb and libc, and libb in turn depends on libc (i.e., has symbols that are resolved by code in libc), then you must mention the libraries in the order libb and libc for the link step and not in the order libc, libb. These KISS linking rules are not all demanded by the Linux linking environment but I follow them anyway because all cross-platform linking issues just simply disappear, and life is good. Thus, I recommend them to others. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: [CMake] Import libraries prefix bug under windows?
On Nov 7, 2007 3:49 PM, Ronan Collobert <[EMAIL PROTECTED]> wrote: > ok thanks -- well, the variable works fine on all system i tried except > windows. i have a workaround, just wanted to mention the problem. > > even under windows, it recognizes it, as it creates "libfoo.dll" and > "libfoo.lib". it is only when linking, that somebody forgot about these > prefixes: it tries to find "foo.lib" instead of "libfoo.lib". > > as all the other systems have a consistent behavior, i considered that > as a bug, but, who knows, as you say. File a bug report for it. It'll get resolved either by removing the global way of doing it, or making it work consistently. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: Re: changing object file extension from ".o"
-- Forwarded message --
From: Matthew McCormick <[EMAIL PROTECTED]>
Date: Nov 7, 2007 5:10 PM
Subject: Re: RE: Re: changing object file extension from ".o"
To: [EMAIL PROTECTED]
The mex compiler is really a bunch of scripts, shell scripts in unix and
mostly a perl script in Windows, that acts as a frontend to a compiler that
you can choose. It does the linking of Matlab API's and whatnot
to the shared library, a "MEX-file" that you create.
It is possible to call the compilers and do the extra linking directly, with
some work, but I would like to use the mex
script for portability across versions, ease of use, and cross platform reasons.
I already do quite a bit of tweaking to the default behavior, e.g.,
SET(CMAKE_CXX_COMPILER
"${MATLAB_DIR}/bin/mex.bat"
CACHE FILEPATH
"Use Matlab's mex.bat directly, set up compiler and options there"
FORCE
)
SET(CMAKE_C_COMPILER
"${MATLAB_DIR}/bin/mex.bat"
CACHE FILEPATH
"Use Matlab's mex.bat directly, set up compiler and options there"
FORCE
)
ENDIF(WIN32)
SET(CMAKE_CXX_COMPILE_OBJECT
"mkdir -p ; -outdir -c
"
)
SET(CMAKE_C_COMPILE_OBJECT
"mkdir -p ; -outdir -c
"
)
SET(CMAKE_CXX_CREATE_SHARED_MODULE
" -output
"
)
SET(CMAKE_C_CREATE_SHARED_MODULE
" -output
"
)
What kind of file and where would I add it to cmake?
Thanks :-)
On 11/7/07, Alexander Neundorf < [EMAIL PROTECTED]> wrote:
>
> On Wednesday 07 November 2007, Matthew McCormick wrote:
> > > > Hi,
> > > >
> > > > Having difficulty changing the object file extension. In my
> > > > CMakeLists.txtI have
> > > >
> > > > SET(CMAKE_C_OUTPUT_EXTENSION ".obj")
> > > > SET(CMAKE_CXX_OUTPUT_EXTENSION ".obj")
> > > >
> > > > but I still get *.o object files.
> > >
> > > Yes, that's too late in the cmake language setup process. What do you
> > > need that for ?
> > >
> > > Alex
> >
> > I'm trying to work with a compiler where you cannot specify the object
> > extension, the Matlab mex (pseudo) compiler.
> > I tried this,
> >
> > $ CMAKE_C_OUTPUT_EXTENSION=".obj" CMAKE_CXX_OUTPUT_EXTENSION=".obj"
> ccmake
> > ../convert_visualsonics_2_mat_src/
> >
> > but it didn't work.
>
> Yes, this doesn't work.
> I know that Matlab has this mex compiler what does it exactly do ?
> Maybe you need to add a file to cmake so it can handle this compiler.
>
> Alex
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: Re: changing object file extension from ".o"
Neat! The mex file I'm also working on also happens to use the Boost Spirit libraries for parsing. Such a cool library. Powerful. The operator overloading is very effective. I'm also using MinGW that was set up with gnumex http://gnumex.sourceforge.net/. I have set up CMake with MEX-file minus the mex script before too, but in Linux instead of Windows. The Windows way seemed more convoluted, and to make it easier for transitions between Matlab versions, I'm trying to use the mex compiler. But your example might be helpful or just a copy or paste of the relevant parts. I'm interested in how you dealt with this Resource Compiler stuff in Windows. It is part of the newer versions (2006 and 2007 I believe). Thanks. On 11/7/07, Maik Beckmann <[EMAIL PROTECTED]> wrote: > > Am Mittwoch 07 November 2007 22:13:32 schrieb Matthew McCormick: > > > > I'm trying to work with a compiler where you cannot specify the object > > extension, the Matlab mex (pseudo) compiler. > > I tried this, > > > > $ CMAKE_C_OUTPUT_EXTENSION=".obj" CMAKE_CXX_OUTPUT_EXTENSION=".obj" > ccmake > > ../convert_visualsonics_2_mat_src/ > > > > but it didn't work. > > I'm coded a bunch of result file parsers (using spirit/spirit2) and > connected > them to Matlab via mex files (*.mexw32 at windows). > > The mex frontend is IMHO a very handy thing for very simple cases where > the an > algorithm is contained in one sourcefile without any external > dependencies. I > never really used it, because I never had this simple cases ;) > > I'm using mingw(sometimes msvc) and CMake for this and I can post an > simple > example if you want me to. Its a little tricky, since there are name > clashes > between the libs in Matlab's library-dir and gcc's own libs (i.e libm). > > My access to Matlab is limited to Windows, so I can't provide a general > solution. > > Regards, > Maik Beckmann > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] RE: Re: changing object file extension from ".o"
On Thursday 08 November 2007, Matthew McCormick wrote:
> -- Forwarded message --
> From: Matthew McCormick <[EMAIL PROTECTED]>
> Date: Nov 7, 2007 5:10 PM
> Subject: Re: RE: Re: changing object file extension from ".o"
> To: [EMAIL PROTECTED]
>
> The mex compiler is really a bunch of scripts, shell scripts in unix and
> mostly a perl script in Windows, that acts as a frontend to a compiler that
> you can choose. It does the linking of Matlab API's and whatnot
> to the shared library, a "MEX-file" that you create.
>
> It is possible to call the compilers and do the extra linking directly,
> with some work, but I would like to use the mex
> script for portability across versions, ease of use, and cross platform
> reasons.
>
> I already do quite a bit of tweaking to the default behavior, e.g.,
>
> SET(CMAKE_CXX_COMPILER
> "${MATLAB_DIR}/bin/mex.bat"
> CACHE FILEPATH
> "Use Matlab's mex.bat directly, set up compiler and options there"
> FORCE
> )
> SET(CMAKE_C_COMPILER
> "${MATLAB_DIR}/bin/mex.bat"
> CACHE FILEPATH
> "Use Matlab's mex.bat directly, set up compiler and options there"
> FORCE
> )
> ENDIF(WIN32)
>
> SET(CMAKE_CXX_COMPILE_OBJECT
> "mkdir -p ; -outdir
> -c "
> )
> SET(CMAKE_C_COMPILE_OBJECT
> "mkdir -p ; -outdir -c
> "
> )
> SET(CMAKE_CXX_CREATE_SHARED_MODULE
> " -output
> "
> )
> SET(CMAKE_C_CREATE_SHARED_MODULE
> " -output
> "
> )
>
> What kind of file and where would I add it to cmake?
It seems it would be Modules/Platform/mex.cmake which would be read when cmake
checks the language support.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Symbian support
Hi Salvatore,
On Monday 05 November 2007, Salvatore Iovene wrote:
> On 11/3/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
...
> > Which compiler do you use ?
>
> mwccsym2.exe (Nokia codewarrior C/C++ compiler for winscw platform) and
> gcce (for GCCE platform)
Please put the attached CMakeDetermineC/CXXCompiler.c/cpp files into Modules/,
then cmake should say "The C compiler identification is Metrowerks". This
means it has detected the compiler correctly.
If you're lucky you don't have to change anything, and the generic compiler
flags will work with mwcc, otherwise you have to create a file
Modules/Platform/Metrowerks.cmake, where the compiler specific variables are
set (see e.g. Linux-SunPro-c.cmake).
For gcce you shouldn't have to do that.
> > What are the naming conventions for object files, static libs, shared
> > libs, executables on Symbian ?
>
> objfilename.o, staticlibname.lib, dllname.dll, executable.exe
>
Attached you can find a file Symbian.cmake, which you should put into
Modules/Platform/, then cmake should load these settings (if you use
CMAKE_SYSTEM_NAME=Symbian). Please have a look in this file, at the end there
are some lines commented out, you should remove the comments from one of the
two options.
Let me know how it works.
Alex
#ifdef __cplusplus
# error "A C++ compiler has been selected for C."
#endif
#ifdef __CLASSIC_C__
# define const
#endif
#if defined(__INTEL_COMPILER) || defined(__ICC)
# define COMPILER_ID "Intel"
#elif defined(__BORLANDC__)
# define COMPILER_ID "Borland"
#elif defined(__WATCOMC__)
# define COMPILER_ID "Watcom"
#elif defined(__MWERKS__)
# define COMPILER_ID "Metrowerks"
#elif defined(__SUNPRO_C)
# define COMPILER_ID "SunPro"
#elif defined(__HP_cc)
# define COMPILER_ID "HP"
#elif defined(__DECC)
# define COMPILER_ID "Compaq"
#elif defined(__IBMC__)
# define COMPILER_ID "VisualAge"
#elif defined(__PGI)
# define COMPILER_ID "PGI"
#elif defined(__GNUC__)
# define COMPILER_ID "GNU"
#elif defined(_MSC_VER)
# define COMPILER_ID "MSVC"
#elif defined(__ADSPBLACKFIN__) || defined(__ADSPTS__) || defined(__ADSP21000__)
/* Analog Devices C++ compiler for Blackfin, TigerSHARC and
SHARC (21000) DSPs */
# define COMPILER_ID "ADSP"
/* IAR Systems compiler for embedded systems.
http://www.iar.com
Not supported yet by CMake
#elif defined(__IAR_SYSTEMS_ICC__)
# define COMPILER_ID "IAR" */
/* sdcc, the small devices C compiler for embedded systems,
http://sdcc.sourceforge.net */
#elif defined(SDCC)
# define COMPILER_ID "SDCC"
#elif defined(_COMPILER_VERSION)
# define COMPILER_ID "MIPSpro"
/* This compiler is either not known or is too old to define an
identification macro. Try to identify the platform and guess that
it is the native compiler. */
#elif defined(__sgi)
# define COMPILER_ID "MIPSpro"
#elif defined(__hpux) || defined(__hpua)
# define COMPILER_ID "HP"
#else /* unknown compiler */
# define COMPILER_ID ""
#endif
static char const info_compiler[] = "INFO:compiler[" COMPILER_ID "]";
/* Include the platform identification source. */
#include "CMakePlatformId.h"
/* Make sure the information strings are referenced. */
int main()
{
return (&info_compiler[0] != &info_platform[0]);
}
/* This source file must have a .cpp extension so that all C++ compilers
recognize the extension without flags. Borland does not know .cxx for
example. */
#ifndef __cplusplus
# error "A C compiler has been selected for C++."
#endif
#if defined(__COMO__)
# define COMPILER_ID "Comeau"
#elif defined(__INTEL_COMPILER) || defined(__ICC)
# define COMPILER_ID "Intel"
#elif defined(__BORLANDC__)
# define COMPILER_ID "Borland"
#elif defined(__WATCOMC__)
# define COMPILER_ID "Watcom"
#elif defined(__MWERKS__)
# define COMPILER_ID "Metrowerks"
#elif defined(__SUNPRO_CC)
# define COMPILER_ID "SunPro"
#elif defined(__HP_aCC)
# define COMPILER_ID "HP"
#elif defined(__DECCXX)
# define COMPILER_ID "Compaq"
#elif defined(__IBMCPP__)
# define COMPILER_ID "VisualAge"
#elif defined(__PGI)
# define COMPILER_ID "PGI"
#elif defined(__GNUC__)
# define COMPILER_ID "GNU"
#elif defined(_MSC_VER)
# define COMPILER_ID "MSVC"
#elif defined(__ADSPBLACKFIN__) || defined(__ADSPTS__) || defined(__ADSP21000__)
/* Analog Devices C++ compiler for Blackfin, TigerSHARC and
SHARC (21000) DSPs */
# define COMPILER_ID "ADSP"
#elif defined(_COMPILER_VERSION)
# define COMPILER_ID "MIPSpro"
/* This compiler is either not known or is too old to define an
identification macro. Try to identify the platform and guess that
it is the native compiler. */
#elif defined(__sgi)
# define COMPILER_ID "MIPSpro"
#elif defined(__hpux) || defined(__hpua)
# define COMPILER_ID "HP"
#else /* unknown compiler */
# define COMPILER_ID ""
#endif
static char const info_compiler[] = "INFO:compiler[" COMPILER_ID "]";
/* Include the platform identification source. */
#include "CMakePlatformId.h"
/* Make sure the information strings are referenced. */
int main()
{
Re: [CMake] improve the CMake language?
Juan Sanchez wrote: I was reading exactly the link you sent, and the same one you accused Brandon of not reading. If there were supplemental materials, you should have sent them. I am not a lawyer. To Juan: Yes. The best place for any license question about source code is, as usual, the source code. In ruby's case, its source code is in SVN at: svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby1.9 That's where you will find LEGAL which has probably the most up to date status of each file not entirely written by the ruby team. If you need further clarification about a source file, you should ask probably in the ruby-core's mailing list. Also, this is only about the (most popular and currently faster) C Ruby we are talking about. There's several other ruby interpreters which are under other licenses. To Brandon: Sorry, yes, that was a mistype. I really meant Ruby is dual licensed as GPL and its own license. Anyway... why are you guys so concerned about cmake's license? To me, as long as the code is open source and forkable, that's all I care for cmake. I'm not planning to make money selling a fork of cmake, borrow its source code, use cmake as a library nor embed it into another program, which are the reasons I might prefer a BSD/MIT license. To be honest, the only compelling languages I've seen so far in this discussion is lua and tcl. This is because they are small and appear to be ideal for embedding. Sure. That's from your POV. For me, a language without good and easy OO is a no-no as experience tells me it will sooner or later run into scalability and maintainability issues. That makes TCL and Lua to me only minimally better than cmake's language in the long run. For me, I would accept either Python or Ruby as a better alternative, even if they are not as small. TCL and Lua are only better for embedding if you were to need cmake to be multithreaded or if cmake would need to initialize a clean interpreter without quitting (two things, afaik, not needed or currently used in cmake). Otherwise, there's not much difference with embedding Ruby, Python, etc. Perl is the only language I would say that has a very difficult API for embedding. Not that speed is super important, but I know of at least one hosting provider making exceptions for ruby scripts, because they just take way too long to run. That's pretty funny. Ruby (1.8) scripts run about the same speed as TCL (ie. neither one is known to be a speed daemon). Ruby1.9 (to become the official ruby in 2008) runs at about the speed of Python (ie. much better than TCL). Lua is certainly a faster language in terms of VM and numeric computations. But for io, string, regex, etc. you are not likely to see a big difference. The next link is *very* un-scientific and I don't endorse it. But it is still an okay website to at least give you a very rough idea of performance: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=python -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Testing exceptions through CTest
You're right. Library's destructor was calling a function that was returning an exception. That in turn called terminate() killing the process. Thank You for your help. Now I have CTest failing the test as it is supposed to. -- Artur Kedzierski -Original Message- From: Bill Hoffman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 18:50 To: Kedzierski, Artur CIV NSWC Corona, PA53 Cc: CMake Mailing List Subject: Re: [CMake] Testing exceptions through CTest Kedzierski, Artur CIV NSWC Corona, PA53 wrote: > Hi, > > I am writing CTest unit tests for a library I've created. > I've utilized CREATE_TEST_SOURCELIST as described in Mastering CMake book. > In one of the test, I pass an invalid value to make sure that an > exception is thrown. > In my test program I have a try-catch around the function call that > passes that invalid > value and inside of the 'catch' I simple return EXIT_FAILURE. For that > test, I've > used SET_TESTS_PROPERTIES(... PROPERTIES WILL_FAIL TRUE). Now, > when I run 'make test', the test doesn't pass with a message > '***Exception: Other'. > How can I tell ctest that the exception is expected? I.e. I need > something like > 'WILL_EXCEPT' property that I could pass to set_tests_properties. > If you are catching the exception, then cmake should not know about it. This sounds like an un-caught exception or some sort of crash. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
I was reading exactly the link you sent, and the same one you accused Brandon of not reading. If there were supplemental materials, you should have sent them. I am not a lawyer. To be honest, the only compelling languages I've seen so far in this discussion is lua and tcl. This is because they are small and appear to be ideal for embedding. Not that speed is super important, but I know of at least one hosting provider making exceptions for ruby scripts, because they just take way too long to run. Juan Gonzalo Garramuño wrote: > Sanchez, Juan wrote: >> This part of the license would concern me. Are all files of interest, >> by other authors, guaranteed to be BSD friendly? >> > > > Again, read LEGAL. You will then find that: > > regex when used with Ruby it is Ruby licensed, based on Onigurama. > utils is BSD, credit going to Lucent Technologies. > gcis Public Domain (Boehmm), albeit now is so heavily modified > there's no resemblance to it any longer (probably the docs need updating). > stis Public Domain. > > Other files may use Perl's Artistic License. > > ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Testing exceptions through CTest
Hi, I am writing CTest unit tests for a library I've created. I've utilized CREATE_TEST_SOURCELIST as described in Mastering CMake book. In one of the test, I pass an invalid value to make sure that an exception is thrown. In my test program I have a try-catch around the function call that passes that invalid value and inside of the 'catch' I simple return EXIT_FAILURE. For that test, I've used SET_TESTS_PROPERTIES(... PROPERTIES WILL_FAIL TRUE). Now, when I run 'make test', the test doesn't pass with a message '***Exception: Other'. How can I tell ctest that the exception is expected? I.e. I need something like 'WILL_EXCEPT' property that I could pass to set_tests_properties. -- Artur Kedzierski ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote: This part of the license would concern me. Are all files of interest, by other authors, guaranteed to be BSD friendly? Again, read LEGAL. You will then find that: regex when used with Ruby it is Ruby licensed, based on Onigurama. utils is BSD, credit going to Lucent Technologies. gcis Public Domain (Boehmm), albeit now is so heavily modified there's no resemblance to it any longer (probably the docs need updating). stis Public Domain. Other files may use Perl's Artistic License. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
For interest, this topic has been brought up before. http://public.kitware.com/pipermail/cmake-promote/2005-December/39.html ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Switching off dependencies at compile time (with Makefiles)?
Josef Karthauser wrote: I guess what I want is an all/fast - to build all the targets in the current directory, but nothing else. Yes, please. So much easier than trying to figure out which targets need to be built. (Especially since there is install/fast...) -- Matthew The time you have spent Reading this lame signature Is now lost to you ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
On Nov 7, 2007 8:55 PM, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote: > Sanchez, Juan wrote: > > This part of the license would concern me. Are all files of interest, > > by other authors, guaranteed to be BSD friendly? > > Other files may use Perl's Artistic License. That's the license I had read, that Ruby is like. The Artistic License. Kind of a PITA, frankly. I mean, yeah, you can put up with it if the software really really does something for you, but I'm not seeing what's so great about Ruby compared to other options to warrant jumping through the legal hoops. Seems like Ruby could stand a license assignment cleanup, so that people don't have to worry about needing an army of lawyers. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Testing exceptions through CTest
Kedzierski, Artur CIV NSWC Corona, PA53 wrote: Hi, I am writing CTest unit tests for a library I've created. I've utilized CREATE_TEST_SOURCELIST as described in Mastering CMake book. In one of the test, I pass an invalid value to make sure that an exception is thrown. In my test program I have a try-catch around the function call that passes that invalid value and inside of the 'catch' I simple return EXIT_FAILURE. For that test, I've used SET_TESTS_PROPERTIES(… PROPERTIES WILL_FAIL TRUE). Now, when I run 'make test', the test doesn't pass with a message '***Exception: Other'. How can I tell ctest that the exception is expected? I.e. I need something like 'WILL_EXCEPT' property that I could pass to set_tests_properties. If you are catching the exception, then cmake should not know about it. This sounds like an un-caught exception or some sort of crash. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
