Aaron Nowack
writes:
> Has anyone been able to get the newest cmake release (2.8.11.2) working
> with Visual Studio 2013 Express RC?
Since yesterday, the newest cmake release is 2.8.12.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.o
outro pessoa
writes:
> The problem is this:
> I am trying to port traverso-daw to FreeBSD-10.x. I have to edit the CMake
> variables. Since the project is not mine, I need to work with a patched
> version. I have tried getting in contact with the original developer.
> Okay, do I need to clear out
[Please CC the cmake user's mailing list]
outro pessoa writes:
> I'm looking at CMakeDetermineCompilerABI_C.bin and the path to
> /usr/local/lib/gcc46 is plain text in the elf file. Besides needing to
> eliminate some log files, is there a cmake argument that can be passed to
> clear all caches
outro pessoa
writes:
> Did it require any extra options outside of: clang bin/, clang lib/ , and
> the implicit link list when you started using "clang-is-compiler"?
It can be as easy as:
CC=clang CXX=clang cmake ...
or alternatively
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
outro pessoa
writes:
> No. In the $PROJECT/CMakeFiles/2. 8.10.2
>
> CMakeCCompiler.cmake 2 KB 10/01/13 03:42:34 [image: File:]
> CMakeCXXCompiler.cmake 2 KB 10/01/13 03:42:35 [image: File:]
> CMakeDetermineCompilerABI_C.bin 6 KB 10/01/13 03:42:34 [image: File:]
> CMakeDetermineCompilerABI_CXX.bin
outro pessoa
writes:
> If I edit the file to use clang as the compiler instead of gcc, will the
> version number be necessary or can I skip that? The libraries are for 3.2
> and 3.3.
Do you mean something like:
cmake -DCAMKE_C_COMPILER=clang-3.3 .
?
The version number there helps when you
"Alan W. Irwin"
writes:
>> I use the emacs mode to reformat CMake code.
>
> I use that as well, but the problem is that appears
> to be the only choice and some developers (although very few, of
> course :-) ) don't use emacs.
You can write a script a script that invokes Emacs in batch mode.
--
Stephen Kelly writes:
> While at it, you comb this thread to see if there are other feature requests
> there which are not in the bug tracker:
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475
Good idea.
Apart from the .i targets, the only non-controversial u
Bill Hoffman
writes:
> On 1/5/2013 3:49 PM, Óscar Fuentes wrote:
>> With the `Unix Makefiles' generator, a foo.i target is generated for
>> foo.cpp. That's very convenient. However, ninja doesn't list such
>> targets under `ninja help' and `ninja
With the `Unix Makefiles' generator, a foo.i target is generated for
foo.cpp. That's very convenient. However, ninja doesn't list such
targets under `ninja help' and `ninja foo.i' complains about unknown
target.
Is this feature missing from the ninja generator? Is it because is hard
to implement o
On a machine with both MinGW and VS installed, some generators (Ninja,
for instance) will use MinGW by default. The only way I know of
instructing cmake to use VS instead is
cmake -G Ninja -DCMAKE_CXX_COMPILER=cl -DCMAKE_C_COMPILER=cl ...
This is quite verbose and triggers some bugs.
Is there a
Clifford Yapp
writes:
> On Sat, Jan 14, 2012 at 3:25 PM, Peter Collingbourne wrote:
>>
>> I managed to test these changes on a Mac and it fixed all but 7
>> test failures, so I rolled it into the ninja-generator-pr branch.
>> In terms of applications I didn't have time to try building anything
>
Michael Hertling
writes:
> But aren't the issues related at least?
Dunno.
> If I understand
> correctly, "cmake --build" invokes MSBuild which
>
> - loads the solution file and the project files,
> - reinvokes CMake via the ZERO_CHECK project/target
> to regenerate them if CMakeLists.txt has
Michael Hertling
writes:
> On 01/09/2012 02:34 PM, David Cole wrote:
>> No trick, but to avoid this, perhaps we should change the "--build"
>> handler to run the cmake configure & generate step before calling out
>> to MSBuild. You can easily do this yourself from the command line by
>> adopting
When MSBuild.exe is used (typically by "cmake --build") for building a
VS2010 project generated by cmake, it correctly invokes cmake for
regenerating the project files if changes to the CMakeLists.txt files
are detected. However, the build does not restart nor abort, so MSBuild
continues using the
The Creative Commons BY 2.5 license used on the Wiki is not compatible
with Debian. LLVM contains a macro taken from it and the Debian guys
filed a bug report:
http://llvm.org/bugs/show_bug.cgi?id=9739
They suggest upgrading to 3.0. CC also suggests using 3.0 instead of
2.5, see the bottom of
ht
Michael Wild writes:
> On 04/06/2011 09:21 AM, Alexey Livshits wrote:
>>> We have a clang.exe and a clang.dll. While building, VS creates
>>> clang.pdb (for the executable) and clang.pdb (for the dll) which
>>> obviously is not right. Is there a way to tell VS to use a different
>>> name for the
We have a clang.exe and a clang.dll. While building, VS creates
clang.pdb (for the executable) and clang.pdb (for the dll) which
obviously is not right. Is there a way to tell VS to use a different
name for the PDB?
___
Powered by www.kitware.com
Visit
Consider this custom_command:
add_custom_command(OUTPUT ${CX_NATIVE_TG_DIR}/CMakeCache.txt
COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${FOO_SOURCE_DIR}
WORKING_DIRECTORY ${CX_NATIVE_TG_DIR})
When it is executed from a Makefile-based generator, no
problem. However, when it is ex
Michael Hertling
writes:
>>> So you add global compiler flags which are not meant to be global? A usual
>>> person would say: "then do not set them globally!".
>>> It's really that simple...
>>
>> No, I want to replace those automatically setted by CMake.
>
> AFAIK, CMake doesn't set compilatio
Hendrik Sattler
writes:
>> "The COMPILE_FLAGS property sets additional compiler flags used to build
>> sources within the target."
>>
>> So it *adds* flags. I want to *set* flags, i.e. replace the existing
>> ones.
>
> So you add global compiler flags which are not meant to be global? A usual
>
Michael Wild writes:
> On 03/14/2011 12:42 AM, Óscar Fuentes wrote:
>> There are target properties such as LINK_FLAGS and LINK_FLAGS_,
>> but I don't see properties for setting compiler flags. This makes
>> impossible to build two targets on the same CMakeLists.txt
Hendrik Sattler
writes:
> Zitat von Óscar Fuentes :
>
>> There are target properties such as LINK_FLAGS and LINK_FLAGS_,
>> but I don't see properties for setting compiler flags. This makes
>> impossible to build two targets on the same CMakeLists.txt with
>> d
There are target properties such as LINK_FLAGS and LINK_FLAGS_,
but I don't see properties for setting compiler flags. This makes
impossible to build two targets on the same CMakeLists.txt with
different compiler flags (I was told that the last value of
CMAKE__FLAGS_ applies to all targets on that
Michael Wild writes:
>>> The point I (and Andreas) wanted to make is that you can just add it. If
>>> it's a system directory, CMake is going to filter it out (I didn't say
>>> duplicates, I said "doesn't even show up ONCE", which means *zero* times).
>>
>> This is a moot point, because /usr/loc
Andreas Pakulat writes:
> On 27.01.11 20:08:06, Óscar Fuentes wrote:
>> Okay, so if I have this:
>>
>> check_include_file(foo.h HAVE_FOO_H)
>>
>> and it succeeds, I have no guarantees that a program such as this:
>>
>> #include "foo.h&quo
Michael Wild writes:
>> Okay, cmake removes duplicated directories that already are on the
>> list. So what?
>>
>> First, I hope that cmake does not optimize this series:
>>
>> A B C A
>>
>> ... to this:
>>
>> A B C
>>
>> or to this:
>>
>> B C A
>>
>> Removing adjacent duplicates is fine,
Michael Wild writes:
>>> No, the bug is in your cmake code. You shouldn't use
>>> USER_DEFINED_INCLUDE_DIR to decide wether to add the path to the
>>> include-directories or not. Instead use the FFI_INCLUDE_PATH variable to
>>> decide that, it won't hurt if FFI_INCLUDE_PATH happens to be /usr/inc
Andreas Pakulat writes:
> On 27.01.11 16:13:09, arrowdodger wrote:
>> Hello. On FreeBSD everything, that distributes with system goes to /usr (i
>> mean includes go to /usr/includes and libs to /usr/lib) and all 3d party
>> stuff goes to /usr/local.
>> And the compiler is intentionally set to loo
If /EHs- /EHs-c- are added with add_definitions, the output of the build
contains warnings:
cl : Command line warning D9025 : overriding '/EHs' with '/EHs-'
cl : Command line warning D9025 : overriding '/EHc' with '/EHc-'
This is because cmake automatically adds /EHsc to the command line
options.
Michael Hertling
writes:
[snip]
> The basic idea is the following: The custom target foo invokes a script
> scandeps.cmake which uses an external dependency scanner - here, gcc's
> -M facility - to get the files zoo.cpp depends on.
[snip]
> This approach works on *nix
> with Makefiles, but I d
Michael Hertling
writes:
>> It would be very convenient to inspect the header files referenced from
>> `zoo.cpp' and associate them with `bar.inc', so when some of those
>> header files are touched `bar.inc' (and hence `foo.cpp') is
>> automatically re-built.
>>
>> Is this possible?
>
> Yes, wit
A file `foo.cpp' has this:
#include "bar.inc"
`bar.inc' is a generated file, and is marked as such. It is generated
processing a file `zoo.cpp' with an utility executed through a custom
command.
It would be very convenient to inspect the header files referenced from
`zoo.cpp' and associate them
Bill Hoffman
writes:
[snip]
> This is a limitation of jom, I know the maintainer of jom said he
> wanted to work on this as a feature, but I don't think he has done it
> yet...
Thanks Bill.
I'll open a bug report on the Qt bug tracker just to let him know that
someone cares about that feature.
Bill Hoffman
writes:
> On 9/24/2010 1:03 PM, Óscar Fuentes wrote:
>> JOM does a nice work compiling multiple files of the same top-level
>> product (.exe, .dll etc) but for some reason it doesn't build multiple
>> top-level targets in parallel. Here I have a project
JOM does a nice work compiling multiple files of the same top-level
product (.exe, .dll etc) but for some reason it doesn't build multiple
top-level targets in parallel. Here I have a project that generates
several independent dlls, each based on one or two source files. JOM
wont build DLL_N+1 unti
Michael Wild writes:
>>> How to know the compiler arguments set by include_directories,
>>> add_definitions, etc?
>>>
>>> CMAKE__FLAGS (with and whitout the uppercase build_type suffix)
>>> doesn't contain anything that was set by the cmake commands mentioned
>>> above.
>>
>> I guess that the l
Óscar Fuentes writes:
> How to know the compiler arguments set by include_directories,
> add_definitions, etc?
>
> CMAKE__FLAGS (with and whitout the uppercase build_type suffix)
> doesn't contain anything that was set by the cmake commands mentioned
> above.
I guess th
How to know the compiler arguments set by include_directories,
add_definitions, etc?
CMAKE__FLAGS (with and whitout the uppercase build_type suffix)
doesn't contain anything that was set by the cmake commands mentioned
above.
___
Powered by www.kitware.
Michael Wild writes:
>> This is quoting hell. Back to configure_file.
>
> What's wrong with my solution? Doesn't even require a custom command...
It is more complex than configure_file, although it has the advantage of
not requiring a .in file to configure. As this code is suppossed to be
unders
Óscar Fuentes writes:
> Andreas Pakulat writes:
>
> [snip]
>
>> add_custom_command( OUTPUT build.h
>> COMMAND cmake -E echo \"\#define FOO \\"bar\\"\"
>> >build.h )
>
> Well, it even makes sense, although it i
Eric Noulard
writes:
[snip]
> May be I was too pushy on that, sorry.
No problem. Thanks for trying to help.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep me
Andreas Pakulat writes:
[snip]
> add_custom_command( OUTPUT build.h
> COMMAND cmake -E echo \"\#define FOO \\"bar\\"\" >build.h
> )
Well, it even makes sense, although it is not immediately
obvious. Thanks!
> You can easily see your mistake by running (n)make VERBOSE=1 to
Michael Wild writes:
> The problem is, CMake has to go through the system shell. Of course,
> CMake could write the command to a file and then invoke a custom
> interpreter from the system shell, but that would probably be very
> inefficient and would require CMake to implement a full shell
> lan
Michael Wild writes:
[snip]
> Perhaps you need to tell us what it is that you are trying to achieve,
> because I suspect that you are over-thinking things and that there is
> a much simpler solution. E.g. what should buildobj.h contain
> (semantically, not the exact strings), and why is it only
Eric Noulard
writes:
> I think you are wrong.
>
> May be you can try the attach script.
>
> try:
> cmake -DYOURSTRING="I like # \ it" -DTHE_FILE=toto.txt -P writeany.cmake
>
> You shouldn't have "quite" problem with the previous approach.
I tried this on Linux:
add_custom_command(OUTPUT ${EMACS
Alexander Neundorf writes:
> ...not sure about that dot here.
>
> Do you have something like
> include_directories ( . )
> in your CMakeLists.txt ?
Okay, problem solved. I was adding the directories with
add_definitions(-I...)
instead of include_directories(...)
Thank you, Alex.
[snip]
Óscar Fuentes writes:
> Alexander Neundorf
> writes:
>
>>> In the C.includescache file config.h is mentioned, twice. So the
>>> dependency scanner detects the file, but then it is ignored. The
>>> config.h file is in D:/dev/other/emacs/qbuild/src/config.h (
Alexander Neundorf
writes:
>> In the C.includescache file config.h is mentioned, twice. So the
>> dependency scanner detects the file, but then it is ignored. The
>> config.h file is in D:/dev/other/emacs/qbuild/src/config.h (the build
>> directory.) This is an excerpt of C.includescache:
>>
>> D
Eric Noulard
writes:
[snip]
> if you need build
> time creation of the file then you may write a CMake script
> "generateMyFile.cmake" which contains such commands and use
>
> add_custom_command( ...
> COMMAND ${CMAKE_COMMAND} -P generateMyFile.cmake
>...)
That approach justs shifts t
For creating a file at build time with a content like this:
#define foo "bar"
I use this on Linux:
add_custom_command(OUTPUT buildobj.h
COMMAND ${CMAKE_COMMAND} -E echo "\\#define foo \\\"bar\\\""
> buildobj.h
)
but that doesn't work on Windows, because it outpus:
\#define foo "bar"
Rem
Eric Noulard writes:
> 2010/7/28 Óscar Fuentes :
>> I'm using cmake 2.8.2 on Linux/make and on Windows/make-mingw32
>>
>> The project configures a template config.cmake producing config.h. That
>> header is included by all C files on the project.
>>
>>
I'm using cmake 2.8.2 on Linux/make and on Windows/make-mingw32
The project configures a template config.cmake producing config.h. That
header is included by all C files on the project.
While building in-source, touching config.h only triggers the rebuild if
config.h is included as
#include "con
Pau Garcia i Quiles
writes:
>> My advice is to start small: with a text editor, edit the top-level
>> project file, then edit the project file of lib/System, which does not
>> depend on any other file. Move the whole tree to somewhere else, open VS
>> and build just the System library. If it work
Bill Hoffman
writes:
[snip]
> Even with the IDE based files if you are using install rules, then the
> CMake executable must be available on the machine doing the
> install. CMake is also used as the program to do the install commands.
> So, CMake is really required for a variety of reasons.
Bu
steve naroff writes:
> Our current thinking is to post process the cmake generated files and
> remove all the absolute paths (since the project files are simply
> text). Since cmake is a black box to me (and I am unfamiliar with it's
> generated 'code'), it's unclear if this a 'good' idea? Or wil
Brad King writes:
[snip]
> In return for the above explanation, I request an explanation as to
> the restrictions that make distributing CMake so hard, particularly
> on machines that already have the entire GNU toolchain. Have you
> ever tried to build GCC 4.4 and all its dependencies from scr
Hello Steve and Eric.
Eric Noulard
writes:
> 2009/12/6 steve naroff :
>>>
>>> May be we can think of "packaging" CMake itself along with the build tree?
>>
>> Packaging the binaries isn't considered acceptable (we need a "pure" source
>> distribution with no binary files).
>
> Sorry for being pi
Tyler Roscoe writes:
> On Sun, Aug 23, 2009 at 09:03:22PM -0400, John Smith wrote:
>> I am using the following test case in an attempt to add a custom
>> command to build an assembly file. The assembly file should be
>> compiled with the C++ compiler driver (which in turn should invoke the
Tyler Roscoe writes:
> On Sun, Aug 16, 2009 at 09:18:31PM +0200, Óscar Fuentes wrote:
>> No, that's right, although the best thing would be to create a
>> dependency on the generated files of libParent instead of on libParent
>> itself, but as the project is quit
This held me confused for 15 minutes or so.
I'm on windows with Mingw's bin directory as the first item on PATH.
`cl' is *not* on the PATH. If I invoke it from the same command line the
shell says that there is no such executable.
Please note the -g parameter instead of -G:
D:\dev\idb-llvm\lp0\
Tyler Roscoe writes:
>> >> The source files of a library depend on generated files from another
>> >> library on its parent directory. Let's call them libParent and libChild.
>> >>
>> >> For the source files on libChild I do
>> >>
>> >> SET_SOURCE_FILES_PROPERTIES(some_source.cpp
>> >> PROP
Tyler Roscoe writes:
> On Sun, Aug 16, 2009 at 09:54:09AM +0200, Óscar Fuentes wrote:
>> The source files of a library depend on generated files from another
>> library on its parent directory. Let's call them libParent and libChild.
>>
>> For t
The source files of a library depend on generated files from another
library on its parent directory. Let's call them libParent and libChild.
For the source files on libChild I do
SET_SOURCE_FILES_PROPERTIES(some_source.cpp
PROPERTIES OBJECT_DEPENDS libParent)
This way I try to delay the com
cmake is
welcomed.
--
Óscar Fuentes
Desarrollo de Software
___
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
Philip Lowman writes:
[snip]
> One suggestion would be if you have non-definition flags you want to add to
> every compilation you make, simply use CMAKE_C_FLAGS or CMAKE_CXX_FLAGS.
>
> if(CMAKE_COMPILER_IS_GNU_CC)
>set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wl,s -save-temps")
> endif()
Would
Philip Lowman writes:
>> > CMAKE_CXX_FLAGS / CMAKE_C_FLAGS is empty by default on Linux unless
>> you've
>> > modified it which may have been what happened. The build type specific
>> > complilation flags are stored in CMAKE_CXX_FLAGS_.
>> > CMAKE_CXX_FLAGS is a base that gets prepended to all o
Hi Philip.
Philip Lowman writes:
>> I have this:
>>
>> add_custom_command(OUTPUT ${LLVM_CONFIG}
>> COMMAND echo "flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CPP_FLAGS}
>> ${CMAKE_C_FLAGS}"
>> more stuff
>>
>>
>> When the custom command executes, this is the output:
>>
>> flags:
>>
>> i.e. the v
I have this:
add_custom_command(OUTPUT ${LLVM_CONFIG}
COMMAND echo "flags: ${CMAKE_CXX_FLAGS} ${CMAKE_CPP_FLAGS} ${CMAKE_C_FLAGS}"
more stuff
When the custom command executes, this is the output:
flags:
i.e. the variables are empty, although I previously used add_definitions
to add
Group <[EMAIL PROTECTED]> writes:
[snip]
> When I use "make install", everything do as I wanted.
> But I can't use "make uninstall". How to deal with it?
http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F
> And I hope you can give me more links about cmake tutorial.
Andreas Pakulat <[EMAIL PROTECTED]> writes:
>> Huh? I'm not aware of that as a limitation - you *do* need the objects
>> in the static library to be
>> position-independant or otherwise compiled as objects to go into a
>> shared library.
>
> Thats ok on linux, to get it working on 64 bit syst
James Mansion <[EMAIL PROTECTED]>
writes:
[snip]
> I think Oscar is wrong here:
>
>>A convenience library works as an object file at link time: it is
>>included on the final executable as any other object file.
>
> Or at least, that's an unnecessarily limited view. The terminology is
> debatable
"Sean Soria" <[EMAIL PROTECTED]>
writes:
> cmake claims to not support convenience libraries. Isn't building a
> static library and then linking it into other libraries the same as a
> convenience library?
A convenience library works as an object file at link time: it is
included on the final ex
Alexander Neundorf <[EMAIL PROTECTED]>
writes:
>> >> The problem is in execute_process. The cmake process created by it is
>> >> taking variable values from the enclosing cmake, so it uses the same
>> >> compiler, configure variables, etc.
>> >
>> > What do you mean by "variables"?
>> > CMake one
Alexander Neundorf <[EMAIL PROTECTED]>
writes:
>> > Doesn't work, you have to do it the other way round: create a custom
>> > target my-special-clean, do what you need, and also execute something
>> > like ${CMAKE_MAKE_COMMAND} clean
>>
>> Sadly, this is not acceptable.
>
> Setting the ADDITIONA
Hello, Alex.
Alexander Neundorf <[EMAIL PROTECTED]>
writes:
>> I wish to execute a command when the `clean' target is invoked. That is,
>> my command shall execute on addition of the normal target action.
>
> Doesn't work, you have to do it the other way round: create a custom target
> my-speci
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Eric NOULARD <[EMAIL PROTECTED]>
writes:
>> The problem is in execute_process. The cmake process created by it is
>> taking variable values from the enclosing cmake, so it uses the same
>> compiler, configure variables, etc.
>
> What do you mean by "variables"?
> CMake one or
> Environment one?
While cross-compiling, I'm trying to avoid depending on previously built
executables, that is, the cross-compile build should create the native
utilities it needs. For this, I'm trying
execute_process(
COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${CMAKE_SOURCE_DIR}
WORKING_DIRECTORY ${CX
A project named Bar includes other source trees like this:
add_subdirectory(../Foo)
It seems that dependencies on Foo's header files are being ignored. When
a header file in Foo's source tree is modified, C++ files on Bar that
includes that header are not rebuilt.
I'll like to investigate this.
Alexander Neundorf <[EMAIL PROTECTED]>
writes:
>> On some circunstances I need to explicitly invoke the linker, which
>> happens to be `ld'. But this is no longer true when
>> cross-compiling. How to know the name of the linker? I see cmake
>> variables containing command lines for linking, but no
Hello.
On some circunstances I need to explicitly invoke the linker, which
happens to be `ld'. But this is no longer true when cross-compiling. How
to know the name of the linker? I see cmake variables containing command
lines for linking, but not the linker command name itself.
--
Oscar
__
Óscar Fuentes <[EMAIL PROTECTED]> writes:
>> macro(add_llvm_library name)
>> add_library(${name} ${ARGN})
>> add_dependencies(${name} ${LLVM_SOURCE_COMMON_DEPENDS})
>>
>> endmacro()
>
> This doesn
Hello, Brad.
Brad King <[EMAIL PROTECTED]> writes:
> Óscar Fuentes wrote:
>> Several libraries depends on a generared header file. For enabling
>> parallel builds I need to state that dependency, and I do it with
>> set_source_files_properties. This happens i
Several libraries depends on a generared header file. For enabling
parallel builds I need to state that dependency, and I do it with
set_source_files_properties. This happens inside a macro:
macro(add_llvm_library name)
if( LLVM_SOURCE_COMMON_DEPENDS )
set_source_files_properties( ${ARGN}
Micha Renner <[EMAIL PROTECTED]>
writes:
> but what is with "make uninstall?"
>
> How can I uninstall my installation?
http://www.cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F
--
Oscar
___
CMake mailing list
CMake@cmake.org
htt
I'm observing something very strange with the "MSYS Makefiles"
generator: after some CMakeLists.txt file is altered, on the next 'make'
cmake is automatically invoked for regenerating the makefiles. Well,
after this is done, some target files are deleted. This is the macro
that creates the targets:
How can I determine the system triplet with CMake (something like
i686-pc-mingw32 or i686-pc-linux-gnu)
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[Sorry for the late response. Supposedly, it is vacation here :-)]
Brad King <[EMAIL PROTECTED]> writes:
> Óscar Fuentes wrote:
>> thinking on a two-phase build, something like this:
>>
>> $ cmake -G "Unix Makefiles" # as llvm-config is not avai
Hello, Brad.
Brad King <[EMAIL PROTECTED]> writes:
> Óscar Fuentes wrote:
>> The script examines library interdependencies dumping the symbol
>> definitions and references they contain. For this, you need to build the
>> libraries first. Later on the build, the exe
Bill Hoffman <[EMAIL PROTECTED]>
writes:
>> If this is not possible, I would like to stop `make' when
>> /my/file/output changes, possibly showing some message to the user
>> instructing him to invoke `make' again.
>>
> You could just return an error code from the command that builds the
> /my/fil
Bill Hoffman <[EMAIL PROTECTED]>
writes:
> Óscar Fuentes wrote:
>> Currently, when `make' is executed and a CMakeList.txt file is out of
>> date, `cmake' is automatically invoked and then `make' continues. Is it
>> possible to do this (on a reliable way)
Óscar Fuentes <[EMAIL PROTECTED]> writes:
> Bill Hoffman <[EMAIL PROTECTED]>
> writes:
[about using shell backquotes embedded on link commands through
`target_link_libraries']
>> I don't even think this will work with cmake 2.6.0, because we use
>> link s
Currently, when `make' is executed and a CMakeList.txt file is out of
date, `cmake' is automatically invoked and then `make' continues. Is it
possible to do this (on a reliable way) with an arbitrary file?
I need to re-execute `cmake' whenever certain file changes. I wonder if
is possible to do th
Bill Hoffman <[EMAIL PROTECTED]>
writes:
>> I just realized another reason why your proposal is not adequate: the
>> libraries and the script must be built before the executable, so, at
>> cmake time, the libraries and the script does not exists.
>>
>> I know this is not portable, but it is intend
Mike Jackson <[EMAIL PROTECTED]> writes:
> Just out of curiosity..
>
> Is the dependency tracking in CMake not adequate enough for your
> project?
No, see below.
> If CMake is used as intended you should not have to manually
> figure out what libraries are needed, CMake should be able to do that
Bill Hoffman <[EMAIL PROTECTED]>
writes:
>> Solved:
>>
>> target_link_libraries(myexe "`/path/to/script arg1 arg2`")
>>
> This is in general a non-portable way to write cmake files, and is not
> guaranteed to work in any version of CMake. This is the same as a
> pkg-config script. The way to do
Bill Hoffman <[EMAIL PROTECTED]>
writes:
>> Solved:
>>
>> target_link_libraries(myexe "`/path/to/script arg1 arg2`")
>>
> This is in general a non-portable way to write cmake files, and is not
> guaranteed to work in any version of CMake. This is the same as a
> pkg-config script. The way to do
Óscar Fuentes <[EMAIL PROTECTED]> writes:
[snip]
Solved:
target_link_libraries(myexe "`/path/to/script arg1 arg2`")
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
We have a shell script that computes the list of libraries that shall
appear on the link comand for every executable. The command looks like
this:
g++ ...flags... object-files... -o myexe `/path/to/script arg1 arg2`
Trying to replicate this with CMake is difficult. My first try was to
put the bac
1 - 100 of 101 matches
Mail list logo
