Hi!
I was able to build three circularly dependent libs with CMake.
Still I strongly recommend listening to the advices of refactoring
your code.
If there is no other way around it here is what I have used.
The procedure to follow ( on Linux ) where libfoo and libbar are
the libraries you have.
Hi, Alex!
What I understood from you message is that:
set ( src a1.c a2.c )
add_executable ( cool ${src} )
*will* detect when a3.c is added. While, the following:
FILE ( GLOB src *.c )
add_executable ( cool ${src} )
*will not* detect the when a3.c is added.
Could you please elaborate
13:01, Alexandru Ciobanu wrote:
Hi!
I was able to find and correct the problem.
I have used the 2.4.7 release sources.
Here is the trivial patch ( also attached):
--- cmake-2.4.7/Source/cmGlobalUnixMakefileGenerator3.cxx
2007-07-16 17:12:31.0 -0400
+++ cmake-2.4.7-x/Source
Hi!
I was able to find and correct the problem.
I have used the 2.4.7 release sources.
Here is the trivial patch ( also attached):
--- cmake-2.4.7/Source/cmGlobalUnixMakefileGenerator3.cxx
2007-07-16 17:12:31.0 -0400
+++ cmake-2.4.7-x/Source/cmGlobalUnixMakefileGenerator3.cxx
Hi!
I am not sure if any previous target related EXCLUDE_FROM_ALL
problems are linked with this one, but what I found is this:
- in CMakeFiles/Makefile2 ( which defines the preinstall
rule ) there is a section that processes the test/ directory.
I removed it and "make install" did work correc
Hi, Alexander!
Yes you are right, the sequence:
make
make preinstall
has the same effect - it builds the targets in the
"EXCLUDED_FROM_ALL" directory.
Regarding the bug reports, I've found one that
exposes the same issue, but it has status fixed,
and was filed for an older version ( 2.2.3):
Hi, Brandon!
I am on 32bit Linux. I've reproduced this on the
following systems (with 2.4.6 and 2.4.7):
- Red Hat Enterprise 5
- SUSE Linux Enterprise Server 10
- Ubuntu 7.04
On these systems cmake generates Makefiles.
Alex Ciobanu
Brandon Van Every wrote:
On 8/1/07, Alexandru Ci
install
... will check all the targets and build the test ...
... will install only the lib ...
At step 4, the test should not be built.
If you guys confirm it, I'll re-add this to the Bug Tracker.
Alex Ciobanu
Alexandru Ciobanu wrote:
Hi Brandon,
This is my bad.
This see
8/1/07, Alexandru Ciobanu <[EMAIL PROTECTED]> wrote:
Hi!
Another observation I have is that the file
cmake_install.cmake is generated correctly,
it does not include the test/ directory.
So I am inclined to think that normally
"make install" should not ckeck the targets
in
Hi!
Another observation I have is that the file
cmake_install.cmake is generated correctly,
it does not include the test/ directory.
So I am inclined to think that normally
"make install" should not ckeck the targets
in test/.
I've found a workaround in one Alexander Neundorf's
posts. The idea
Hi!
Given the following simple setup:
add_subdirectory ( lib )
add_subdirectory ( tests EXCLUDE_FROM_ALL )
When I run make it correctly builds only the lib.
When I run "make install" it checks for the presence of *all* the
targets including the ones from test/.
Why is that? And is that
Hi, Alexander!
I've been able to implement Precompiled Headers for a project. We use
the Intel compiler on Linux, but still, the steps are the same:
- compile a stdafx.cpp with /Yc ( gives the .pch file )
- compile the normal source files using /Yu
Here is a rough sketch of a possible solu
ave a workaround, because PCH is very important
in our project, it reduces compile time considerably. =)
Alex Ciobanu
Bill Hoffman wrote:
Alexandru Ciobanu wrote:
Hi!
I am posting the workaround I have found.
Using the following command:
set_target_properties ( mytgt PROPERTIES LINK_FLAGS DEFINE_S
the intel compiler.
The -D seems to not bother it.
Alex Ciobanu
Alexandru Ciobanu wrote:
Hi!
Is there a way to remove -Dtarget_EXPORTS from the compile flags?
I know it has its utility for shared libs, but in my case it does not
allow me to use Precompiled Headers ( with Intel C++ Compile
Hi!
Is there a way to remove -Dtarget_EXPORTS from the compile flags?
I know it has its utility for shared libs, but in my case it does not
allow me to use Precompiled Headers ( with Intel C++ Compiler ).
This specific compiler wants to have exactly the same flags when
creating and using precom
PROTECTED]>> wrote:
On 2007-06-29 09:04+0800 Clark J. Wang wrote:
> On 6/28/07, Alan W. Irwin <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>>
>> On 2007-06-28 10:08-0400 Alexandru Ciobanu wrote:
>> > If I use t
Peter.
On 6/28/07, *Alexandru Ciobanu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thanks Alan, it works.
=)
Alan W. Irwin wrote:
> On 2007-06-28 10:08-0400 Alexandru Ciobanu wrote:
>
>> Hi!
>>
>> I am trying to build
Thanks Alan, it works.
=)
Alan W. Irwin wrote:
On 2007-06-28 10:08-0400 Alexandru Ciobanu wrote:
Hi!
I am trying to build kernel modules with CMake. To do that I
use the command below:
add_custom_target ( manager.ko ${kbuild_cmd}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/linux
Hi!
I am trying to build kernel modules with CMake. To do that I
use the command below:
add_custom_target ( manager.ko ${kbuild_cmd}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/linux
DEPENDS ${src} linux/Kbuild
)
The problem is that nobody depends on this custom target and so it
t saves me 10min in build time, as I use this ${obj}
list to relink directly. =)
Alex Ciobanu
James Bigler wrote:
Hi,
Alexandru Ciobanu wrote:
Hi!
I am using CMake to build three libraries. They are located
in separate folders (with separata CMakeLists.txt):
libA/
./CmakeLists
hand?
sincerely,
Alexandru Ciobanu
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
21 matches
Mail list logo
