Andreas,
sorry but it took me a little longer to get the diff done, but now I
included some more things I found useful. Currently everything runs fine
for PPC2003,SP2003,WM5,WM6, and CE5.0, based on your configuration and
some additional flags set - basically it's all in there what we (or at
Hi
How to handle windows dll dependences in CMake.
CMakeList.txt
=
ADD_LIBRARY(MY_DLL MODULE ${ALL_SOURCES} ) #-- MSVC generates MY_DLL.dll
and one
# small MY_DLL.lib that has to
be linked
# to
Original-Nachricht
Datum: Fri, 10 Oct 2008 09:21:12 +0200
Von: Sören Freudiger [EMAIL PROTECTED]
An: cmake@cmake.org
Betreff: [CMake] [cmake] windows dll and TARGET_LINK_LIBRARIES
Hi
How to handle windows dll dependences in CMake.
CMakeList.txt
=
Hi Sören,
for shared libraries use (module is for plugins not to be linked to
executables)
ADD_LIBRARY(MY_DLL SHARED ${ALL_SOURCES} )
and also use test instead of test.exe
TARGET_LINK_LIBRARIES(test MY_DLL)
Does this work?
Werner
On 10.10.2008, at 09:21, Sören Freudiger wrote:
Hi
How
What was the final resolution of this issue? Was this fixed in CMake
2.6.2? If not, will this fix be included in the future releases?
Thanks!
Luke
Summary
0005150: VERBOSE=1 does not print flags passed
Description
CMake CVS does not print out the flags passed to the cl.exe
Luke Kucalaba wrote:
What was the final resolution of this issue? Was this fixed in CMake
2.6.2? If not, will this fix be included in the future releases?
It is fixed in 2.6.2.
-Bill
___
CMake mailing list
CMake@cmake.org
I am building with CMake 2.6.2 using nmake, but I'm not seeing the
compiler/linker flags when passing VERBOSE=1. All I see is output that
looks like this:
[ 63%] Building CXX object
DWidgets/CMakeFiles/DWidgets-SL-dbg.dir/Windows/DWX_ImagePanel.cpp.obj
cd
I have a question about knowing when you have run cmake enough times to
resolve all the cache variables for a project. In the CMake explanation
on the main website, regarding generation using the cmake.exe program
from the command-line in non-interactive mode, it says It can be
difficult to know
Luke Kucalaba wrote:
I am building with CMake 2.6.2 using nmake, but I'm not seeing the
compiler/linker flags when passing VERBOSE=1. All I see is output that
looks like this:
[ 63%] Building CXX object
DWidgets/CMakeFiles/DWidgets-SL-dbg.dir/Windows/DWX_ImagePanel.cpp.obj
cd
Luke Kucalaba wrote:
I have a question about knowing when you have run cmake enough times to
resolve all the cache variables for a project. In the CMake explanation
on the main website, regarding generation using the cmake.exe program
from the command-line in non-interactive mode, it says “It
I think the reason we need to run cmake.exe multiple times is because we
typically have a main project that automatically sets the options of
dependent projects. For example, our main executable project has an
option ENABLE_NETWORKING, which then triggers automatic changes for
various global
Hm. If I do an out-of-source build, I get .o files. If I do an in-source
build, I get .obj.
(Yes, I know in-source builds are considered Evil; the lead engineer wants to
do 'em that way, not sure why, so I was testing to see if they'd work, noticed
that I was getting .obj files.)
Does this
Luke Kucalaba wrote:
I think the reason we need to run cmake.exe multiple times is because we
typically have a main project that automatically sets the options of
dependent projects. For example, our main executable project has an
option ENABLE_NETWORKING, which then triggers automatic changes
No, it doesn't make sense. Can you construct a minimal example that
demonstrates this?
If not, there must be something in your project files that differentiates
between in-source and out-of-source builds...?
Are you changing compilers based on in-source/out-of-source?
The in-source/out-of-source
Thanks Bill, I understand exactly what you are talking about. I looked
into our cmake project structure, and ran some tests. I think we
originally started out using a sequentially correct organization, but we
ran into problems with the Include_Directories() command passing down
the include
I posted an issue on the mantis bug tracker a while ago regarding supporting
the /LTCG option for the MSVC71 generator. The issue history indicates this
problem is fixed, but with CMake 2.6.2 the correct flags are still not being
generated for the MSVC71 project files and nmake makefiles.
Correction, that email somehow got corrupted wrt the newlines. These
should be on two separate lines:
Set(EXE_DEF somedef) #executable defs
Set(LIB_DEF somedef) #library def overrides
Sorry about that,
Luke
-Original Message-
From: Luke Kucalaba
Sent: Friday, October 10, 2008 1:46
I have no idea how to construct an example, I'm afraid, though I'm willing to
try. But there's nothing in the project files that makes such a distinction as
far as I can tell.
The compiler is the same - it's a cross-compiler, and is being invoked as a
script, since it's a 2-pass deal (compiles
I've got three libraries, A, B, C. C uses symbols from B, and B uses
symbols from A.
When I build these libraries as static libraries (libA.a, libB.a, and
libC.a), the linker is perfectly happy to produce libC.a even if I
haven't told it about B. It seems that all that matters is, when I'm
Hi Klaas,
I'm quite sure, that
set(VARIABLE)
will clear it.
Werner
klaas.holwerda wrote:
Hi,
The find_path documentation says:
If the file in a directory is found the result is stored in the variable
and the search will not be repeated unless the variable is cleared.
So how do i clear
Hi,
Convey, Christian J CIV NUWC NWPT wrote:
I've got three libraries, A, B, C. C uses symbols from B, and B uses
symbols from A.
When I build these libraries as static libraries (libA.a, libB.a, and
libC.a), the linker is perfectly happy to produce libC.a even if I
haven't told it about
21 matches
Mail list logo
