Re: [CMake] Problem using VS 2012 Express and CMake

[Óscar Fuentes]

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.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting compiler for cmake

[Óscar Fuentes]

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 the CMakeTmp files?

If you started with an empty build directory and set the compiler to
clang, no, you don't need to clean anything. Why should you do?

Is clang/clang++ the default compiler for FreeBSD-10? Maybe the cmake
version you are using does not know about that fact and insists on using
gcc/g++. If that's the problem, set CC and CXX environment variables (or
CMAKE_C_COMPILER and CMAKE_CXX_COMPILER cmake variables ) as I explained
on a previous message upon your *first* invocation of cmake on a clean
build directory and it should just work. If it doesn't, please show the
exact command you executed and its output.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting compiler for cmake

[Óscar Fuentes]

[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 and keep the progress at the current point?
> Thanks muchly.

Don't reuse a build directory when switching compilers. Start with an
empty one.

Are you experiencing difficulties with the instructions I gave you? You
shouldn't care about the scripts that comes with CMake for building with
Clang. The task does not require changes on those scripts.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting compiler for cmake

[Óscar Fuentes]

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++ ...

Use a full path to clang/clang++ if they are installed on custom
directories outside of PATH.

If you wish tho use libc++ or other goodies I suppose(*) that you can
add the options in your CMakeLists.txt:

if( "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" )
...
endif()


[*] I don't use those libraries, so never checked that the above works.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting compiler for cmake

[Óscar Fuentes]

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 6 KB 10/01/13 03:42:35 [image: File:]
> CMakeSystem.cmake 1 KB 10/01/13 03:42:31 CompilerIdC
> 10/01/13 03:42:32 CompilerIdCXX
>
> Sooner than later, we will need to see what and what does not build with
> clang. I have 2 version numbers: 3.2 & 3.3

Sorry, but stil is not clear to me what you are asking. If you mean if
CMake works with Clang as the C and C++ compiler, yes it does. I'm using
it for C++ projects since a few years ago (at least Jan 2011) so there
should be no problem with Clang 3.2.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting compiler for cmake

[Óscar Fuentes]

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 have more than one version of
clang installed. Otherwise, you can omit it.

BTW, please send this type of questions only to the user's list.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake Code Beautifier

[Óscar Fuentes]

"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.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ninja and *.i targets

[Óscar Fuentes]

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 unimplemented
feature I see is the generation of .s targets. Created a feature request
here:

http://public.kitware.com/Bug/view.php?id=13839

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Ninja and *.i targets

[Óscar Fuentes]

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 foo.i' complains about unknown
>> target.
>
> This is a missing feature.  Can you create a feature request for it in
> the bug tracker?

Done:

http://public.kitware.com/Bug/view.php?id=13838

Thanks.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Ninja and *.i targets

[Óscar Fuentes]

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 or just lack of time?

I'm using cmake 2.8.9 and ninja 1.0.0 on Linux.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Choosing the right compiler

[Óscar Fuentes]

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 cleaner way to tell cmake to use VS instead of MinGW with a
given generator?

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake + Ninja

[Óscar Fuentes]

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
>> other than CMake itself and LLVM/Clang (both successfully), but please
>> let me know if there are any other problems with BRL-CAD.
>
> Confirmed - working now on Mac building BRL-CAD - thanks!

Does anyone know what changes are required to make the Ninja generator
work on Windows? I know nothing about the CMake C++ base nor I see
anything obvious on the source code of the Ninja generator but, maybe,
with a starting point, something could be done with some hours I can
devote to that task. I mailed Peter Collingbourne some weeks ago but
received no response.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSBuild and automatic project file regenation

[Óscar Fuentes]

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 been modified,
> - does *not* use the regenerated ones for building, so the
>   affected projects/targets are left inherently out-of-date.

Yep.

> Moreover, even an additional subsequent "cmake --build" command doesn't
> rebuild; in fact, it does nothing, as though there is no dependency of
> a project/target on its own project file.

That doesn't happen here. The next "cmake --build" works fine (cmake
2.8.4, VS 10)

> AFAICS for now, it's solely
> David's hint, i.e. "cmake . && cmake --build .", that results in the
> project being actually rebuilt after CMakeLists.txt has changed,
> unless one uses the "--clean-first" option.
>
>>> If so, I would strongly support a feature request in
>>> this respect since, IMO, it's actually quite confusing that CMake's
>>> "--build" command does anything but rebuilding.
>> 
>> I agree.
>
> Do you file a feature request / bug report?

Nope.

> Personally, I'd like to be
> sure that after a "cmake --build" command, everything is up-to-date as
> it is with Makefiles, provided it can be realized with MSBuild at all.

Obviously, how MSBuild works when the project files are regenerated on
the fly is a bug. I have no idea about how hard is to fix it, though.

> Try .

Hmmm... After reading your example, I can't say for sure that when
`cmake --build' worked the second time here it didn't cointain changes
on the source files too.

CMake with VS 10 and/or MSBuild is pesky, apart from the problems
MSBuild has on its own. I'm looking at using other generators that
support parallel builds. JOM is not truly parallel (it only builds a
toplevel target at once). Ninja looks like the right thing, but doesn't
work on MS Windows.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] MSBuild and automatic project file regenation

[Óscar Fuentes]

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 the pattern:
>> 
>>   cmake . && cmake --build . --config Release

Fortunately my cmake scripts are simple enough so the extra invocation
does not add much to the build.

Thanks David.

>> This is a good idea for a feature request. Not sure if we should just
>> always do that by default and provide a way to turn off with a
>> "--no-regenerate", or vice-versa with a "--please-generate-first" ...
>> :-)

The effect of --no-regenerate would be the same as the current buggy
behavior (MSBuild.exe uses outdated project files). IMHO the
--please-generate-first is the right thing.

> Just out of curiosity: In [1], item (1), I reported on the fact that
> one can modify a project's CMakeLists.txt, and "cmake --build" will
> reconfigure/regenerate, but not rebuild. Is this the same issue the
> OP asks about?

No.

> If so, I would strongly support a feature request in
> this respect since, IMO, it's actually quite confusing that CMake's
> "--build" command does anything but rebuilding.

I agree.

> [1] http://www.mail-archive.com/cmake@cmake.org/msg39596.html

This returns 404.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] MSBuild and automatic project file regenation

[Óscar Fuentes]

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 outdated project files that it previously read,
ending some time later with lots of error messages from the compiler or
linker, hence wasting time, causing confusion and making difficult to
notice that a regeneration had happened.

Is there any trick for stopping MSBuild as soon as cmake ends
regenerating the project files?

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] License of Wiki code snippets is not Debian-compatible

[Óscar Fuentes]

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

http://creativecommons.org/licenses/by/2.5/

Is it possible to upgrade the Wiki license to 3.0?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] DLL and EXE with same base name: clash in VS.

[Óscar Fuentes]

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 PDB?
>> 
>> You can use different project name for exe and set the output name via
>> OUTPUT_NAME property.
>
> CMake uses prefix+base+".pdb" to generate the PDB file name, however I
> didn't dig deep enough to find out what `base' is, just that it is
> obtained with cmTarget::GetName(). Whether that refers to the target
> name or the OUTPUT_NAME, I couldn't find out easily, so you'll have to
> experiment ;-)

It is OUTPUT_NAME. The target name for clang.dll is libclang and the
build creates clang.pdb (and clang.ilk ...)

If I understand correctly what Michael says, the .pdb file name is
hardcoded.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] DLL and EXE with same base name: clash in VS.

[Óscar Fuentes]

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 other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Platform tests counts as errors.

[Óscar Fuentes]

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 executed from the VS 2008 IDE, failed
platform tests are signaled as errors:

2>-- Looking for sys/dir.h
2>CheckIncludeFile.c
2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
'sys/dir.h': No such file or directory
2>-- Looking for sys/dir.h - not found

At the end, the custom_command is signaled as failed by the IDE because
of those "errors".

First of all, why

2>CheckIncludeFile.c
2>CheckIncludeFile.c(1) : fatal error C1083: Cannot open include file: 
'sys/dir.h': No such file or directory

is shown in the middle of the usual

2>-- Looking for sys/dir.h
2>-- Looking for sys/dir.h - not found

?

Second, what can I do so the IDE does not interpret failed platform
tests as errors?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No _FLAGS_ target property.

[Óscar Fuentes]

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 compilation flags by itself, perhaps unless a
> specific toolchain/platform file enforces this. Rather, the flags are
> roughly set up as follows - for C compilations:
>
> 1) CMAKE_C_FLAGS for all configurations; explicitly set or initialized
>by the CFLAGS environment variable when CMake is run initially.
> 2) Addition of CMAKE_C_FLAGS_ for the configuration.
> 3) Addition of COMPILE_FLAGS source/target properties.
>
> If you set neither CFLAGS/CMAKE_C_FLAGS nor CMAKE_C_FLAGS_ nor
> COMPILE_FLAGS, your source files should be compiled without any flags,

Say CMake, say a toolchain/platform file, once a project is started it
comes with the "standard" flags for compiling in the chosen mode (debug,
release, ...) and, IIRC, in some cases some other flags which are
deemed as "good to have" are added too.

> so the art is to specify the latters such that each source file will
> be compiled with the correct/desired set of them.
>
> However, you're right insofar that there's no possibility to specify
> flags which will be used solely for a certain target *and* a certain
> configuration, but in my experience, this is almost never necessary.
> Do you have a special problem in this regard, i.e. a flag that must
> be activated for one target in one configuration only?

Generally speaking, I had a case for building the same sources with
different flags. One project I maintain (LLVM) compiles an utility that
is used to generate files later in the same build. The problem is VC++
in Debug configurations: the debug VC++ runtime makes the utility to
perform excruciatingly slow. Someone was annoyed enough by that to
create a patch that builds the utility and one library it uses in
optimized mode when the user activates an option. The ugly part of the
patch was a trick for building the library used by the utility twice:
one with the usual Debug configuration (required because that library is
used by everything else on the project) and another with optimization
flags. He resorted to creating an extra directory for building the
optimized version, because CMAKE_C*_FLAGS* affects all targets defined
on the same CMakeLists.txt file.

Fortunately our problem can be easily solved on a totally different way,
but I was surprised by the lack of target properties for setting the
compiler flags.

[snip]

> Finally, if you really need to drop a flag from a compilation command
> and can't avoid its addition by other means, you could use one of the
> RULE_LAUNCH_COMPILE properties to intercept the compiler command and
> adjust the command line to whatever is necessary [2]. Regrettably,
> this is restricted to the Makefile generators.

IDE support is required. Whenever I see a feature restricted to Makefile
generators, I know it is not useful to me. I wish the docs showed this
restriction at the top of the description of the feature :-/

> Alternatively, you
> might modify the CMAKE_C_COMPILE_OBJECT rule variable within the
> affected directories, especially w.r.t. the  placeholder,
> see [3].

I cannot access the link because gmane mangled it, but I guess that
CMAKE_C_COMPILE_OBJECT has the same restriction as CMAKE_C_FLAGS (it
acts with the same value over all targets defined on the same
CMakeLists.txt).

[snip]

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No _FLAGS_ target property.

[Óscar Fuentes]

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 
> person would say: "then do not set them globally!".
> It's really that simple...

No, I want to replace those automatically setted by CMake.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No _FLAGS_ target property.

[Óscar Fuentes]

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 with
>> different compiler flags (I was told that the last value of
>> CMAKE__FLAGS_ applies to all targets on that
>> CMakeLists.txt).
>> 
>> So why no per-target compile flags?
>
> You could misuse COMPILE_DEFINITIONS and COMPILE_DEFINITIONS_
> for that...

I think that that is the same case as COMPILE_FLAGS property: it just
adds its contents to whatever CMAKE_*_FLAGS* has.

I'm afraid of compiler errors & warnings of the sort of "option -foo is
incompatible with option -bar"

So as it seems that there is no way of replacing the compiler flags at
the target level, is it an omission worth a bug report or is it
something that was decided?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] No _FLAGS_ target property.

[Óscar Fuentes]

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
>> different compiler flags (I was told that the last value of
>> CMAKE__FLAGS_ applies to all targets on that
>> CMakeLists.txt).
>>
>> So why no per-target compile flags?
>
> RTFM? The following line is directly derived from the words in your question:
> set_target_properties(myTarget PROPERTIES COMPILE_FLAGS "-foo -bar")
>
> Or maybe your question was wrong?

"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.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] No _FLAGS_ target property.

[Ó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
different compiler flags (I was told that the last value of
CMAKE__FLAGS_ applies to all targets on that
CMakeLists.txt).

So why no per-target compile flags?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

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/local/include and several other paths
>> which are searched by default by cmake are not system directories in
>> FreeBSD.
>
> No it's not. If you have e.g. /usr/local/include/foo.h and you do
>
> find_path(FOO_INCLUDE_DIR foo.h)
> if(FOO_INCLUDE_DIR)
>   include_directories("${FOO_INCLUDE_DIR}")
> endif()
>
> you don't have to care, because -I/usr/local/include will show up on the
> command line. If foo.h happened to be in /usr/include, things would be
> (kind of) fine again, because CMake filters that one out and thus
> doesn't clutter your command line.

I said that it is a moot because what you describe is, precisely, what I
was describing as problematic: the code above injects /usr/local/include
on the preprocessor search list, after that another find_path (with a
hard-coded path selected by the user) returns /home/joe/include and that
is appended to the preprocessor search list. But if the user required a
custom directory for the headers found with the second find_path
possible is because he wants to override those installed on a
system-wide directory such as /usr/local/include. If the user doesn't
check the commands executed by `make', he will not notice that the build
is using the headers stored in /usr/local/include.

> After all, you do use CMake because it's smarter than your compiler.
> Otherwise you could just use some dump shell script.

CMake and the compiler do very different tasks, their smartness can't be
compared.

the find_* commands and the FindXXX modules in general works hard for
finding things. I guess that if it where practical, they would be
programmed for performing a complete filesystem scan. The fact that
Unixes have a series of catch-all directories for headers and libraries
and that cmake is used by people who don't know (nor care) about how it
does its stuff and assume that it is a smart tool that does the Right
Thing, is something that makes me think that that sort of nasty problems
will happen from time to time. Unfortunately, what the Right Thing is
can't be easily decided. I'm inclined to making everything explicit and
not trying to be smart when that can cause subtle problems, but that's
just me. I understand that others may prefer everyday convenience.

>>> And yes, CMake simplifies A B C A to A B C, which is perfectly fine
>>> because the trailing A doesn't have any effect whatsoever.
>>
>> The semantics of #include is one of the most underspecified points of
>> the C++ standard. It is up to the compiler vendor to decide what to do
>> with #include. Each vendor uses its own algorithm (unless they decided
>> on cloning the behavior of somebody else's compiler) and I've suffered
>> subtle bugs due to that fact while porting applications. IIRC the
>> standard says nothing about rewinding the search list for every lookup,
>> but I'm ready to admit that in practice removing trailing duplicates
>> makes no effect for all existing compilers and the vast majority of
>> cmake users will appreciate that feature, although I wouldn't bet my
>> neck on it.
>
> That's true. But I bet that no vendor would be that insane to search the
> include-directories in reverse order, or make it probabilistic, making
> it more likely that a header gets picked up from a certain directory if
> it is mentioned more often ;-)

:-)

Well, I must confess that when I wrote that removing trailing duplicates
on the search path can affect semantics, I was thinking that it was
actually true for some implementation, but at the same time I was unable
to recall which one. No longer:

http://www.delorie.com/gnu/docs/gcc/cpp_11.html

#include_next is like #include but it doesn't rewind the search list. I
would be quite surprised if there is no C/C++ software project that
depends on having a duplicates (even adjacent duplicates!) on the search
path.

>>> But you could have found that out by yourself in about 20 seconds...
>> 
>> Please spare the inflammatory language for some other thread. Thanks.
>
> Sorry for being snarky. I can only blame a foul mood due to a nasty cold
> I caught...

No problem. It happens to me too (catching the flu and being snarky, not
necessarily at the same time.)

>> Have I missed something?
>
> I reiterate Andreas' answer from yesterday. But there IS one point where
> the removal of system directories could wreak potential havoc, but even
> then, there's nothing CMake could do about it. Assume this situation:

[snip]

Agreed. This whole business is a can of worms. But I understand that
CMake can't do much about it, apart from applying some checks that could
alert the user that something is fishy. I'm not sure if it is worth the
effort.

___
Powered by

Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

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"
>> 
>> will compile, becasue foo.h may be found on a directory not included on
>> the compiler's default search list.
>
> Actually, thats wrong. If you look at the check_include_file macro
> you'll notice that it uses try_compile. That in turn (as documented in
> man cmake) creates a cmakelists.txt which only adds include dirs set via
> the INCLUDE_DIRECTORIES variable passed into the internal cmake call and
> otherwise just uses a simple add_executable() call for the source. 
>
> The convenience paths are only added to things such as find_path,
> find_library etc. They are _not_ added to compiler invocations
> automatically.
>
> Hence the above check_include_file would fail if foo.h is in
> /usr/local/include and your compiler does not search there by default.
>
> So you'd need to either set CMAKE_REQUIRED_INCLUDES or use find_path and
> then add the director to include_directories().

Okay, this helps a lot.

The original problem arised when a user who was trying to add support
for a library reported that cmake was successfully finding the headers
and library file (with find_*) without the user's help, but failing at
build time because the compiler was unable to #include to headers. Then
he reported that the library was located under a catch-all directory
that is not part of the default search list of the compiler (/usr/local
in FreeBSD) and I was reluctant to add it to include_directories,
because that may cause problems like the described on my previous post
if there is some library already installed on those catch-all extra
directories (note that the problem does not arise if the library's
headers are on /usr/include instead of /usr/local/include, because cmake
takes care of /usr/include occurrences of the header search list, as
Michael explained)

All this is a potential source of confussion, but I understand that
cmake is trying to be helpful and the problem is directly related to the
established practice on Unixes.

>> But there is another install of thelib on /usr/local, and that install
>> is the one that will be used by our build because we end having this
>> search list:
>> 
>> /usr/local/include /home/oscar/thelib/include
>
> This has nothing to do with the default paths of the compiler, all you
> need to do with this is fix the order of include's of your target or
> source files. You'd run into compile problems (or compiling against the
> wrong lib version) no matter wether cmake searches in /usr/local/include
> for foo.h or not - unless you actually wanted cmake to _not_ find the
> foo.h header at all.
>
> If you want to ensure that /home/oscar/thelib/include is being searched
> before /usr/local/include then use include_directories with its BEFORE
> parameter so it ends up at the front of the list. This is the same thing
> if you'd create the compiler command yourself in a shell.

When there is a series of libraries to be located and the user is
allowed to give a custom location for each of them, that approach is not
easy to implement.

Thanks.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

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, but removing duplicates in general
>> makes difficult to debug the build and may affect semantics.
>> 
>> Second, the topic here is that we are forced to jump through hops
>> because cmake tries to be helpful. It looks for files into places but
>> then it is up to us to figure out if those places must be added to the
>> list of header and library paths. That's not convenient at all, quite
>> the contrary, it is messy and confusing, as we are experiencing.
>
> 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/local/include and several other paths
which are searched by default by cmake are not system directories in
FreeBSD.

> And yes, CMake simplifies A B C A to A B C, which is perfectly fine
> because the trailing A doesn't have any effect whatsoever.

The semantics of #include is one of the most underspecified points of
the C++ standard. It is up to the compiler vendor to decide what to do
with #include. Each vendor uses its own algorithm (unless they decided
on cloning the behavior of somebody else's compiler) and I've suffered
subtle bugs due to that fact while porting applications. IIRC the
standard says nothing about rewinding the search list for every lookup,
but I'm ready to admit that in practice removing trailing duplicates
makes no effect for all existing compilers and the vast majority of
cmake users will appreciate that feature, although I wouldn't bet my
neck on it.

> But you could have found that out by yourself in about 20 seconds...

Please spare the inflammatory language for some other thread. Thanks.

> IMHO you're the one trying to jump through hoops that aren't even there...

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"

will compile, becasue foo.h may be found on a directory not included on
the compiler's default search list.

Okay, so I have to add something like

  figure_out_where_foo_h_really_is
  include_directories( where_foo_h_is )

Not nice, but let's go ahead.

We end having something like /usr/local/include (or /opt/local/include
or /opt/pkg/include etc) on the search list.

We now test for the presence of some third party library ("thelib"). We
have an user-settable variable for using just in case we want to use an
specific install, and we use it:

cmake -DTHELIB_IS_HERE=/home/oscar/thelib .

The search mechanism for thelib looks into that directory first and
succeeds, as it should. We add the corresponding directory:

include_directories( ${THELIB_INCLUDE_PATH} )

But there is another install of thelib on /usr/local, and that install
is the one that will be used by our build because we end having this
search list:

/usr/local/include /home/oscar/thelib/include

Have I missed something?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

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/include.
>> 
>> FFI_INCLUDE_PATH will evaluate to TRUE whenever find_library succeeds,
>> which means that the path will always be added with
>> include-directories. This has two consequences:
>> 
>>  1. It pollutes the command line for the compiler. This is ugly and
>>  inconvenient while debugging the build.
>> 
>>  2. It affects the search order of include headers with subtle
>>  effects. An example: if you later execute another include_directories
>>  with a user-defined custom location for some set of headers that
>>  override those provided by the system, you have a problem because
>>  /usr/include already comes before the path you are adding.
>> 
>>> The reason cmake searches in /usr/local in addition to /usr is simply a
>>> convenience matter. Its a common prefix to have non-distribution software
>>> installed in and for the same reason things like /opt/local, /opt/csw and
>>> /usr/openwin are being searched for by default.
>> 
>> That's not a convenience here. We have to
>> 
>> if( we are on BSD )
>>   add paths /usr/local/include /opt/local/include etc
>>   same for libraries
>> endif()
>> 
>> which is ugly as hell, puts a lot of crap on the command line and may
>> create conflicts due to the altered search order.
>> 
>> IMO cmake should look by default on the directories where the compiler
>> automatically looks for. All other directories should be left for the
>> user to add, as he does while compiling something that picks a header or
>> library from a place not included on the default search path of the
>> compiler and linker.
>
>
> Sorry, but that is just a *LOT* of BS. Have you actually tried it?!

Have you actually read the thread?

> Check out the following:

[snip]

> That's right, -I/usr/include doesn't even show up ONCE, although I added
> it three times using include_directories().

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, but removing duplicates in general
makes difficult to debug the build and may affect semantics.

Second, the topic here is that we are forced to jump through hops
because cmake tries to be helpful. It looks for files into places but
then it is up to us to figure out if those places must be added to the
list of header and library paths. That's not convenient at all, quite
the contrary, it is messy and confusing, as we are experiencing.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake performs search for includes/libs in non-default compiler search paths.

[Óscar Fuentes]

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 look only in /usr/include. The same
>> is for linker - it's looking for libs only in /usr/lib by default. So, if
>> user want to use some 3d-party library, he should add -I/usr/local/include
>> and -L/usr/local/lib to build command.
>> 
>> Now, i'm using find_library() and find_path() to locate 3d-party library in
>> such way:
>> 
>> > find_path(FFI_INCLUDE_PATH ffi.h PATHS ${USER_DEFINED_INCLUDE_DIR})
>> > find_library(FFI_LIBRARY_PATH ffi PATHS ${USER_DEFINED_LIB_DIR})
>> >
>> I'm expecting that search will not succeed until i supply CMake with
>> additional directories to search. But it's succeeds because
>> CMAKE_SYSTEM_PREFIX_PATH from Modules/Platform/UnixPaths.cmake is set to
>> "/usr;/usr/local;/". And this file is included by
>> Modules/Platform/FreeBSD.cmake.
>> 
>> Later i'm doing:
>> 
>> > if(${USER_DEFINED_INCLUDE_DIR})
>> >   include_directories(${FFI_INCLUDE_DIR})
>> > endif()
>> >
>> 
>> On FreeBSD it leads to "No such file or directory: ffi.h" error. So here is
>> the question: Is this a CMake bug?
>
> 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/include.

FFI_INCLUDE_PATH will evaluate to TRUE whenever find_library succeeds,
which means that the path will always be added with
include-directories. This has two consequences:

 1. It pollutes the command line for the compiler. This is ugly and
 inconvenient while debugging the build.

 2. It affects the search order of include headers with subtle
 effects. An example: if you later execute another include_directories
 with a user-defined custom location for some set of headers that
 override those provided by the system, you have a problem because
 /usr/include already comes before the path you are adding.

> The reason cmake searches in /usr/local in addition to /usr is simply a
> convenience matter. Its a common prefix to have non-distribution software
> installed in and for the same reason things like /opt/local, /opt/csw and
> /usr/openwin are being searched for by default.

That's not a convenience here. We have to

if( we are on BSD )
  add paths /usr/local/include /opt/local/include etc
  same for libraries
endif()

which is ugly as hell, puts a lot of crap on the command line and may
create conflicts due to the altered search order.

IMO cmake should look by default on the directories where the compiler
automatically looks for. All other directories should be left for the
user to add, as he does while compiling something that picks a header or
library from a place not included on the default search path of the
compiler and linker.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Disabling exceptions and rtti on VS

[Óscar Fuentes]

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.

How can I remove /EHsc from the command line options before adding
/EHs-c- ?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Following dependencies through generated header file

[Óscar Fuentes]

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 don't know if it's suitable for other generators
> or IDE's.

At some point on the past, the project did something similar for
regenerating library dependencies on the fly. That feature was removed
by someone because "it was an ugly hack". And indeed it was, but it kept
a working build in circunstances where now breaks. Its major drawback
what that it only worked well with makefile generators. Obtaining header
dependencies has the added problem that each compiler has its own method
for getting them.

I think that the procedure described on your previous post is the one to
consider.

Thanks Michael.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Following dependencies through generated header file

[Óscar Fuentes]

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, with a bit of trickiness:

[snip]

Thanks for idea, Michael, sounds interesting, although having to use a
library is an incovenience, mainly for the people who use IDEs. (The
project I'm working on would need more than 20 such libraries)

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Following dependencies through generated header file

[Óscar Fuentes]

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 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?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake, JOM and multiple top-level targets

[Óscar Fuentes]

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.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake, JOM and multiple top-level targets

[Óscar Fuentes]

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 that generates
>> several independent dlls, each based on one or two source files. JOM
>> wont build DLL_N+1 until DLL_N is finished. This means that only one cpu
>> core is working for a long part of the build.
>>
>> Is this a limitation of JOM or an oversight of CMake?
>>
>
> This is a job limitation.

What this means?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake, JOM and multiple top-level targets

[Óscar Fuentes]

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 until DLL_N is finished. This means that only one cpu
core is working for a long part of the build.

Is this a limitation of JOM or an oversight of CMake?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Obtaining info about the compiler command arguments

[Óscar Fuentes]

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 lack of response indicates that there is no way to do
>> that. Why so basic feature is missing? Something with the internals of
>> cmake that makes it hard to implement?
>
> Well, your question isn't very clear. Are you interested in the
> compiler flag (i.e. -I or -D) or would you like to query the active
> include directories and definitions?

I'm interested on the literal parameters as they are passed to the
compiler.

> The former are available through the variables CMAKE_INCLUDE_FLAG_C
> and CMAKE__DEFINE_FLAG, although AFAIK the latter may not be set
> and defaults to -D.
>
> The latter are available through the directory properties
> INCLUDE_DIRECTORIES and DEFINITIONS. But doing some RTFM would have
> told you that...

Yes, I RTFM. My test code contained a typo on the variable's name :-(
This remembers me why, being a bad typist, I try to avoid so much the
languages that accept undefined variables.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Obtaining info about the compiler command arguments

[Óscar Fuentes]

Ó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 that the lack of response indicates that there is no way to do
that. Why so basic feature is missing? Something with the internals of
cmake that makes it hard to implement?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Obtaining info about the compiler command arguments

[Óscar Fuentes]

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.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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
understandable by people with very slim knowledge about cmake, the
simplest solution wins.

On that sense the add_custom_command was best, because when they see
"echo" and the redirection to the file they immediately guess what's
going on.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

Ó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 is not immediately
> obvious. Thanks!

I spoke too soo. This command:

add_custom_command(OUTPUT buildobj.h
  COMMAND ${CMAKE_COMMAND} -E echo \"\#define BUILDOBJ \\"foo bar\\"\"
  > buildobj.h
  )

works fine on Windows. But on Linux it the file contents are this:

#define BUILDOBJ "foo\ bar"

This is quoting hell. Back to configure_file.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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 messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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 see the
> actual cmake -E execution.

IMHO if "echo" creates different output for the same literal string on
different platforms, that's a problem.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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
> language.

Another option for cmake is to appropriately quote the string so the
system shell does not alter it. Consider

cmake -E echo "#hello"

cmake would put on the Unix makefile something like

cmake -E echo "\#hello"

and on windows MinGW makefile or VS project it would be

cmake -E echo "#hello"

[snip]

> But we still don't know what your general goal is, WHY you need this
> and why e.g. a simple add_definitions() isn't enough (because so far I
> haven't seen anything that requires you to do this stuff dynamically
> at build-time).

This is not the issue. As mentioned on the previous posts, the question
is how much confidence can I have on the platform independence of the -E
commands. The stated goal is to provide platform isolation. We have seen
that this is not completely true.

But if you insist on knowing the context that raised the issue, it
consisted on the requirement of creating a header file containing a
#define with a quoted list of the names of the source files of the
project. configure_file is a solution, but requires having a
pre-existing .in file and I'll like to avoid polluting the source tree
as much as possible. Then add_custom_command seemed a good fit.
Maintenance-wise, it is simpler than configure_file+file.in or
file(WRITE+configure_file and has the added feature of regenerating the
file if it is deleted by mistake.

So here we are.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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 known at
> build time?

I "solved" this specific instance with configure_file. It is not as
convenient as the original add_custom_command method but it works.

What really concerns me is the general problem: a CMake command that
acts on a platform-dependent way when the existence of those "-E"
commands are motivated, precisely, for the cross-platform nature of
CMake. Maybe I should file a bug report and see how it fares.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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_BUILD_DIR}/src/buildobj.h
  COMMAND cmake -DYOURSTRING="#define BUILDOBJ" -DTHE_FILE=buildobj.h -P 
writeany.cmake
  COMMENT "Creating buildobj.h"
  )

It didn't create the file. So tried this:

add_custom_command(OUTPUT ${EMACS_BUILD_DIR}/src/buildobj.h
  COMMAND cmake -DYOURSTRING="\#define BUILDOBJ" -DTHE_FILE=buildobj.h -P 
writeany.cmake
  COMMENT "Creating buildobj.h"
  )

It put this text on the resulting file:

#define\ BUILDOBJ

That's not quite what I wanted.

I would say that having to write and invoke a script for this trivial
task seems way too much trouble imposed by an otherwise absolute
time-saver as cmake is.

>> The task here is to write a literal string containing a "special"
>> character (#) to a file, at build time. For "cmake -E echo" it requires
>> platform-dependent escape sequences. My idea about the cmake -E commands
>> was that they purpose is to abstract platform differences, but seems
>> that that is not entirely correct, as they inherit some traits from the
>> underlying platform. Or is it a bug?
>
> I would say a feature :-)
>
> You do not want to have to "escape" some sequences

I'm happy escaping whatever as much sequences as necessary. What is not
okay is to change escape rules depending on the plataform (or worse,
depending on the shell cmake uses for the generator. "Mingw Makefiles"
-> cmd.exe, "MSYS Makefiles" -> sh.exe)

[snip]

> More seriously I think it's complicated to avoid system specific
> issues with a command like "echo".

It should be possible to pass an arbitrary string (containing
backslashes if necessary) to "echo" and send it to the console or
redirected to a file on a platform independent way. That means avoiding
any middleman that may reinterpret certain characters as per its own
rules. If you pass the string through the shell, all hopes of platform
independence are gone.

> I think that if you tell me what you would expect I may probably gives
> you an example of mine were YOUR bug is a feature for ME.

I doubt that, because on the end we want the same: saying "take this
string and put it on that file." We can then open the file and test
that, effectively, the string is there.

OTOH I can't think of a real application for this sort of behavior of
the "echo" command. That is, nothing that you could achieve invoking the
platform's shell.

> That said, that's my own opinion, I may be wrong.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Configured C header dependency problem

[Óscar Fuentes]

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]

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Configured C header dependency problem

[Óscar Fuentes]

Ó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 (the build
>>> directory.) This is an excerpt of C.includescache:
>>>
>>> D:/dev/other/emacs/git/src/alloc.c
>>> config.h
>>> D:/dev/other/emacs/git/src/config.h
>>
>> This looks like it decided for D:/dev/other/emacs/git/src/config.h instead 
>> of 
>> D:/dev/other/emacs/qbuild/src/config.h .
>> What's the exact compile command (from make VERBOSE=1) ?
>
> This is from Linux:
>
> cd /home/oscar/dev/other/emacs/qbuild/src && /usr/bin/gcc -Demacs
> -DHAVE_CONFIG_H -I. -I/home/oscar/dev/other/emacs/qbuild/src
> -I/home/oscar/dev/other/emacs/git/src -I/usr/include/freetype2 -o
> CMakeFiles/qemacs.dir/alloc.c.o -c
> /home/oscar/dev/other/emacs/git/src/alloc.c

Since the C.includescache excerpt showed above is from MinGW, maybe it
is is more clear to show the command of that build:

cd D:\dev\other\emacs\qbuild\src && C:\apps\msys\1.0\mingw\bin\gcc.exe
-Demacs -DHAVE_CONFIG_H -DHAVE_NTGUI -g
-I. -ID:/dev/other/emacs/git/nt/inc -ID:/dev/other/emacs/qbuild/src
-ID:/dev/other/emacs/git/src -o CMakeFiles\qemacs.dir\alloc.c.obj -c
D:\dev\other\emacs\git\src\alloc.c

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Configured C header dependency problem

[Óscar Fuentes]

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:/dev/other/emacs/git/src/alloc.c
>> config.h
>> D:/dev/other/emacs/git/src/config.h
>
> This looks like it decided for D:/dev/other/emacs/git/src/config.h instead of 
> D:/dev/other/emacs/qbuild/src/config.h .
> What's the exact compile command (from make VERBOSE=1) ?

This is from Linux:

cd /home/oscar/dev/other/emacs/qbuild/src && /usr/bin/gcc -Demacs
-DHAVE_CONFIG_H -I. -I/home/oscar/dev/other/emacs/qbuild/src
-I/home/oscar/dev/other/emacs/git/src -I/usr/include/freetype2 -o
CMakeFiles/qemacs.dir/alloc.c.o -c
/home/oscar/dev/other/emacs/git/src/alloc.c

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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 the problem to a separate cmake script, but
it still remains.

The task here is to write a literal string containing a "special"
character (#) to a file, at build time. For "cmake -E echo" it requires
platform-dependent escape sequences. My idea about the cmake -E commands
was that they purpose is to abstract platform differences, but seems
that that is not entirely correct, as they inherit some traits from the
underlying platform. Or is it a bug?

[snip]

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Does the echo command use the system shell?

[Óscar Fuentes]

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"

Removing the backslashes before `#' fixes the problem on Windows, but
then breaks the Linux build.

This looks as if `echo' was using the system shell for doing the job,
because the escapes works differently on each system.

What's the right way to write the above command so it works on all
platforms?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Configured C header dependency problem

[Óscar Fuentes]

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.
>>
>> While building in-source, touching config.h only triggers the rebuild if
>> config.h is included as
>>
>> #include "config.h"
>>
>> but not as
>>
>> #include 
>>
>> While building out of source, touching config.h does not trigger the
>> rebuild of the C files not matter how the header is used.
>>
>> Touching any other header file triggers the rebuild of the corresponding
>> C source files.
>>
>> The project follows the pattern
>>
>> platform macros
>> configure config.cmake -> config.h (using configure_file)
>> add_subdirectory
>> add_executable(foo file1.c file2.c ...)
>
> Did you try adding the  config.h to your list of files in add_executable ?
>
> Do not forget to
> set_source_files_properties(config.h PROPERTIES GENERATED TRUE)

Thanks for the suggestions. Just tried them, separately and combined. No
change.

OTOH, I would expect from configure_file to automatically do that, and
from the depedency scanner to detect config.h.

>> This is what I do on other projects, without problems. Any suggestion?
>
> May be config.h is found in some add_executable/add_library for
> those project?

Nope.

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:/dev/other/emacs/git/src/alloc.c
config.h
D:/dev/other/emacs/git/src/config.h
stdio.h
-
limits.h
-
setjmp.h
-
signal.h
-
pthread.h
-
lisp.h
D:/dev/other/emacs/git/src/lisp.h
process.h
D:/dev/other/emacs/git/src/process.h
intervals.h
D:/dev/other/emacs/git/src/intervals.h
puresize.h
D:/dev/other/emacs/git/src/puresize.h
buffer.h
D:/dev/other/emacs/git/src/buffer.h
window.h
D:/dev/other/emacs/git/src/window.h
keyboard.h
D:/dev/other/emacs/git/src/keyboard.h
frame.h
D:/dev/other/emacs/git/src/frame.h
blockinput.h
D:/dev/other/emacs/git/src/blockinput.h
character.h
D:/dev/other/emacs/git/src/character.h
syssignal.h
D:/dev/other/emacs/git/src/syssignal.h
termhooks.h
D:/dev/other/emacs/git/src/termhooks.h
setjmp.h
-
unistd.h
-
fcntl.h
-
fcntl.h
-
w32.h
D:/dev/other/emacs/git/src/w32.h
malloc.h
-
stdio.h
-

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Configured C header dependency problem

[Ó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.

While building in-source, touching config.h only triggers the rebuild if
config.h is included as

#include "config.h"

but not as

#include 

While building out of source, touching config.h does not trigger the
rebuild of the C files not matter how the header is used.

Touching any other header file triggers the rebuild of the corresponding
C source files.

The project follows the pattern

platform macros
configure config.cmake -> config.h (using configure_file)
add_subdirectory
add_executable(foo file1.c file2.c ...)

This is what I do on other projects, without problems. Any suggestion?

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

[Óscar Fuentes]

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 works, that's good. Proceed to
>> write a script for automating the absolute->relative path conversion.
>
> You are wasting your time.
>
> It's not going to be that easy. You will need to replace all the calls
> to CMake with generated stuff. Even in the improbable case you
> succeed, you would be giving people something which somewhat works,
> you would not be shipping the actual buildsystem but some kind of a
> pseudo-pre-geneated buildsystem.

You are right.

> Morale: anal retentive people must learn that opening your ass to
> something new may make you happier.

It is not so easy. Anal retentive people have the right personality
traits for doing QA and certification work.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

[Óscar Fuentes]

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.

Bummer. I completely forgot about this.

Steve, ditch the idea about the absolute->relative path conversion. You
really need to distribute CMake with the LLVM/clang sources, either as
source or as binary, and add a .bat for bootstrapping the thing. Is that
acceptable for your clients?

[snip]

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

[Óscar Fuentes]

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 will I bump
> into other gotcha's?

I suggested that option to you on the past.

My guess is that the VS project files generated by CMake depends less on
absolute paths than the Makefiles generated for other build
systems. Building in-source maybe diminishes the amount of work too.

As LLVM/clang have no external dependencies, the problem is simpler. If
VS is installed on C: and the LLVM source and build directories are on
C: too, the problem is even simpler, because you can always replace an
absolute path with a relative one.

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 works, that's good. Proceed to
write a script for automating the absolute->relative path conversion.

> Any advice is appreciated...you have a lot more experience with this
> than I do!

Nor really. I investigated a bit when you asked but found essentially
what Eric and Brad explained on this thread. 

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

[Óscar Fuentes]

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 scratch?
> It's do-able, but the effort is much greater than installing CMake.
>
> If there is any reason not to install CMake other than "it's another
> dependency", perhaps we can address it.  If the only reason is that
> "it's another dependency", consider that once CMake is installed it
> can find all the *other* dependencies automatically on most systems.

My knowledge about Steve's circumstance is just a bit more detailed than
what he exposed here, but I have experience on even stricter
environments and can explain how the thing goes:

A department's work is to certify some piece of software for some
purpose (release to the public, internal use, etc). They have the source
code (LLVM/clang, on this case) and hence they need a compiler
(VC++). LLVM/clang has no external dependencies, it only uses the system
libraries. So adding CMake to the requirements is to add a dependency
where none was required before.

The people who do that kind of work is very strict ("anal retentive" if
you prefer) and will resist any change on their work routine.

If Steve sneaks CMake's source code with the LLVM/clang source base and
adds a script for building the whole package, maybe the "clients" will
not care. If he adds installing CMake and invoking it for generating the
VC++ project files, it is very likely that he will find a strong
resistance.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Copying cmake generated files to another machine

[Óscar Fuentes]

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 picky but you don't "require a pure source".
>
> You want to have the file used by your target
> build system (Makefile or any other "project file") to be shipped with
> your source tree.

In the past, LLVM/clang had a manually crafted Visual Studio project
file. That worked fine for the purposes of the OP. It was "pure source"
because you obtained it directly from the svn repository along the
project source code and it was ready to build with VS, no intermediate
steps required. The VS project file was removed and this is causing
problems to the OP, because the "pure source" requirement is imposed
upon him by somebody else.

[snip]

>> A spin on your idea is to package the CMake source itself (and build
>> it from scratch, prior to building llvm/clang). Unfortunately, this
>> approach is quite "heavy" (but may be the cleanest given the
>> constraints).

For "the others" this would require:

1. build cmake.
2. invoke cmake for configuring LLVM/clang.
3. invoke VS for building the LLVM/clang.

You can solve 1&2 with a .bat file. With cmake 2.8, you can build LLVM
from the .bat file too (with the new "cmake --build" feature, IIRC), but
I guess that "them" are having too much fun building LLVM with the VS
IDE :-)

> I see. Personnally I have another point of view regarding this.  Once
> I decided to go for a CMake build system for my project, I consider
> CMake to be part of the compiler suite.
>
> If I require a compiler to be installed for compiling the source of my
> project I do require CMake to be installed too.

That is very sensible but, unfortunately, the OP can't do much about it.

[snip]

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_command using CMAKE_CXX_FLAGS

[Óscar Fuentes]

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  
>> assembler after pre-processing), and I am building up a  
>> CMAKE_CXX_FLAGS variable from separate pieces:
>
> I think you can just hand your .S files to add_library(). Did you try
> searching the ML archives or google for how to handle assembler files
> with CMake?

Assembler support is broken, at least for masm/64 as some user reported
here some days ago.

  enable_language(ASM_MASM)
  set(sources ${sources} X86CompilationCallback_Win64.asm)

My users say that with the previous code the build pretends to compile
the assembler file as if it were a C file.

If the other assemblers are broken too, I guess this is the reason
people are trying workarounds.

[snip]

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] OBJECT_DEPENDS and target-level dependency.

[Óscar Fuentes]

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 quite large, it doesn't impact parallel
>> builds too much.
>
> Ok now I'm curious: why would a dependency on the generated files
> themselves be the "best thing"? You could still do it that way, though
> it's more work and I do not yet see any benefit.

If the source files on the libChild depended on the generated files
alone instead of the entire libParent, they could be built as soon as
the generated files are delivered, instead of waiting for libParent.

The generation of those files are grouped into a custom target. There is
a dependency of libParent on that custom target. I guess that creating a
depedency of libChild on the custom target would do the trick.

The important info of this thread to me is that you don't need
OBJECT_DEPENDS for creating dependencies on generated files. Just create
a dependency of the library or executable on the custom target that
triggers the generation of the files. The sources will not be compiled
until the custom target is finished.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] A curiosity: cmake detects the wrong compiler when -g is used instead of -G

[Óscar Fuentes]

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\build\mingw\debug>cmake -g "MinGW Makefiles" 
-DLLVM_ROOT=d:/dev/llvm/svnDebugMinGW44 -DCMAKE_BUILD_TYPE=Debug ../../..
-- Check for working C compiler: cl
-- Check for working C compiler: cl -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: cl
-- Check for working CXX compiler: cl -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- /INCREMENTAL:NO
-- Configuring done
-- Generating done
-- Build files have been written to:
D:/dev/idb-llvm/lp0/build/mingw/debug

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] OBJECT_DEPENDS and target-level dependency.

[Óscar Fuentes]

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
>> >> PROPERTIES OBJECT_DEPENDS libParent)
>> >> 
>> >> This way I try to delay the compilation of some_source.cpp until
>> >> libParent is finished.
>> >
>> > Can you just use add_dependencies (libChild libParent)?
>> 
>> Then this means that the source files of libChild will not be compiled
>> until libParent is fully built, right?
>
> Yes. Is there some reason you don't want this to happen?

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 quite large, it doesn't impact parallel
builds too much.

Thanks again.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] OBJECT_DEPENDS and target-level dependency.

[Óscar Fuentes]

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 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 compilation of some_source.cpp until
>> libParent is finished.
>
> Can you just use add_dependencies (libChild libParent)?

Then this means that the source files of libChild will not be compiled
until libParent is fully built, right?

>> cmake 6.4.4, unix makefiles, gnu make, linux.
>
> There is no CMake 6.4.4.

2.6-patch 4

Thanks.

-- 
Ó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://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] OBJECT_DEPENDS and target-level dependency.

[Óscar Fuentes]

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 compilation of some_source.cpp until
libParent is finished.

But when make -j4 attempts to build some_source.cpp it fails saying that
it doesn't know how to make libParent.

Is this a bug on cmake or I'm using the wrong approach?

cmake 6.4.4, unix makefiles, gnu make, linux.

-- 
Óscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] DejaGNU.

[Óscar Fuentes]

A project has a large number of DejaGNU tests and it is unfeasible to
translate them to CTest.

So far I think it is possible to configure and drive DejaGNU from cmake
for running all the test suite, but not parts or individual tests.

Any experiences or advices on how to deal with DejaGNU from 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://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_C*_FLAGS undefined.

[Óscar Fuentes]

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()

Wouldn't this conflict with the cache?

> add_definitions() was originally intended for preprocessor definitions
> only.  If you're using it to non-definition compilation flags I have no idea
> how you'll be able to pull those out again.

As per my interpretation of the docs, add_definitions is the recommended
way of adding extra compiler options. I may wrong.

>> OTOH, what happens if the user sets CFLAGS and other environment
>> variables that affects the build after cmake is run? I ask just out of
>> curiosity, as I know that the method I'm using for configuring the file
>> does not take into account this possibility.
>
> You can set CFLAGS and/or CXXFLAGS but they only work before the first
> configure.  After that they are ignored.  If you need to change
> CFLAGS/CXXFLAGS after that the best way is to modify CMAKE_C_FLAGS and
> CMAKE_CXX_FLAGS in the CACHE.

Thanks.

>> I can't believe that there is not a simple method for knowing such a
>> basic piece of information as "which compiler switches and options are
>> used for compiling source files of language X?" so it seems that I'm
>> missing something.
>
> There might be a better way to do this I'm not aware of.  If so hopefully
> someone else can chime in.

Okay. Thanks for your help so far Philip.

-- 
Oscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_C*_FLAGS undefined.

[Óscar Fuentes]

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 of the build
>> solutions.
>> >
>> > The command pasted below works for me on CMake 2.6.4 RC3 Win32 using the
>> > MinGW generator (it outputs the flags used to compile during a Release
>> > build).  If something like this doesn't work for you can you reply with
>> your
>> > version of CMake and generator you're using?
>> >
>> > add_custom_target(foo COMMAND C:/cygwin/bin/echo.exe flags:
>> > ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE})
>>
>> CMAKE_CXX_FLAGS_RELEASE works, but it is not enough. It still misses the
>> definitions and other options which are passed to the
>> compiler. CMAKE_CXX_FLAGS, as noted on my previous message, is empty.
>>
>
>
>> add_custom_command(OUTPUT ${LLVM_CONFIG}
>>   COMMAND echo "flags: ${CMAKE_CXX_FLAGS_DEBUG} ${CMAKE_CPP_FLAGS}
>> ${CMAKE_C_FLAGS}"
>>  COMMAND echo 's...@llvm_cppflags@!${CMAKE_CPP_FLAGS}!' > temp.sed
>>  COMMAND echo 's...@llvm_cflags@!${CMAKE_C_FLAGS}!' >> temp.sed
>>  COMMAND echo 's...@llvm_cxxflags@!${CMAKE_CXX_FLAGS}!' >> temp.sed
>>  # TODO: Use general flags for linking! not just for shared libs:
>>  COMMAND echo 's...@llvm_ldflags@!${CMAKE_SHARED_LINKER_FLAGS}!' >> temp.sed
>>  COMMAND echo 's...@libs@!!' >> temp.sed# TODO: System
>> libs
>>  COMMAND echo 's...@llvm_buildmode@!${CMAKE_BUILD_TYPE}!' >> temp.sed
>>  COMMAND sed -f temp.sed < ${LLVM_CONFIG_IN} > ${LLVM_CONFIG}
>> # some stuff omitted
>>  DEPENDS ${FINAL_LIBDEPS} ${LLVM_CONFIG_IN}
>>  COMMENT "Building llvm-config script."
>>  )
>>
>> This builds an script that knows the compiler and linker options used
>> for building the libraries. Later, other (third party) software can
>> query the script and check those options for ensuring compatibility with
>> the libraries.
>>
>> `configure_file' is not okay because the "configuration" must be
>> executed at build time. CMAKE_CXX_FLAGS and co. are also empty at cmake
>> time though, so `configure_file' would have the same problem.
>
>
>
> You might want to have a look at the COMPILE_DEFINITIONS target property.

That's interesting, but its contents is sans the -D:

_GNU_SOURCE __STDC_LIMIT_MACROS __STDC_CONSTANT_MACROS

instead of

-D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS

This can be overcomed with string manipulation. But the docs says that
only flags beginning with -D or /D are added to this property. Where the
rest of the flags go?

add_definitions(-DFOO -Wl,s -save-temps)

will put FOO into the COMPILE_DEFINITIONS property, bug how can I access
the other flags?

> Another option of course is you can use configure_file() and

As explained on my previous message, configure_file is not adequate: the
file to be configured is generated at build time.

OTOH, what happens if the user sets CFLAGS and other environment
variables that affects the build after cmake is run? I ask just out of
curiosity, as I know that the method I'm using for configuring the file
does not take into account this possibility.

[snip]

> Can you attach a trivial reproducer of your problem?  I guess I'm hung
> up on what variables you're talking about that you think would change
> between CMake configure time and building time?  As far as I know the
> variables in your Makefile with the sole exception of make variables
> like VERBOSE=1 are all determined at CMake time.  configure_file()
> should make your life quite a bit easier I think.

Even if configure_file were adequate, the variables CMAKE_C_FLAGS
CMAKE_CXX_FLAGS etc are empty, when I expect them to have the full
compiler options for the current build type, including the stuff
introduced with add_definitions.

I can't believe that there is not a simple method for knowing such a
basic piece of information as "which compiler switches and options are
used for compiling source files of language X?" so it seems that I'm
missing something.

-- 
Oscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_C*_FLAGS undefined.

[Óscar Fuentes]

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 variables are empty, although I previously used add_definitions
>> to add flags and the makefile uses the optimization flags that
>> corresponds to the selected build type.
>>
>> How can I access the effective values of the flags used when the
>> makefile is generated?
>
> 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 of the build solutions.
>
> The command pasted below works for me on CMake 2.6.4 RC3 Win32 using the
> MinGW generator (it outputs the flags used to compile during a Release
> build).  If something like this doesn't work for you can you reply with your
> version of CMake and generator you're using?
>
> add_custom_target(foo COMMAND C:/cygwin/bin/echo.exe flags:
> ${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE})

CMAKE_CXX_FLAGS_RELEASE works, but it is not enough. It still misses the
definitions and other options which are passed to the
compiler. CMAKE_CXX_FLAGS, as noted on my previous message, is empty.

I'm using 2.6.1 on Linux, gnu makefiles.

> Also, to possibly anticipate your next question: On Makefile generators you
> should be able to get the current build type being used by the end user by
> referencing CMAKE_BUILD_TYPE.

CMAKE_BUILD_TYPE contains the correct build type.

To expand a bit, this is what I'm trying to do:

add_custom_command(OUTPUT ${LLVM_CONFIG}
  COMMAND echo "flags: ${CMAKE_CXX_FLAGS_DEBUG} ${CMAKE_CPP_FLAGS} 
${CMAKE_C_FLAGS}"
  COMMAND echo 's...@llvm_cppflags@!${CMAKE_CPP_FLAGS}!' > temp.sed
  COMMAND echo 's...@llvm_cflags@!${CMAKE_C_FLAGS}!' >> temp.sed
  COMMAND echo 's...@llvm_cxxflags@!${CMAKE_CXX_FLAGS}!' >> temp.sed
  # TODO: Use general flags for linking! not just for shared libs:
  COMMAND echo 's...@llvm_ldflags@!${CMAKE_SHARED_LINKER_FLAGS}!' >> temp.sed
  COMMAND echo 's...@libs@!!' >> temp.sed# TODO: System libs
  COMMAND echo 's...@llvm_buildmode@!${CMAKE_BUILD_TYPE}!' >> temp.sed
  COMMAND sed -f temp.sed < ${LLVM_CONFIG_IN} > ${LLVM_CONFIG}
# some stuff omitted
  DEPENDS ${FINAL_LIBDEPS} ${LLVM_CONFIG_IN}
  COMMENT "Building llvm-config script."
  )

This builds an script that knows the compiler and linker options used
for building the libraries. Later, other (third party) software can
query the script and check those options for ensuring compatibility with
the libraries.

`configure_file' is not okay because the "configuration" must be
executed at build time. CMAKE_CXX_FLAGS and co. are also empty at cmake
time though, so `configure_file' would have the same problem.

Thanks for looking into this.

-- 
Oscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMAKE_C*_FLAGS undefined.

[Óscar Fuentes]

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 flags and the makefile uses the optimization flags that
corresponds to the selected build type.

How can I access the effective values of the flags used when the
makefile is generated?

-- 
Oscar

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to deal with "make uninstall" ?

[Óscar Fuentes]

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.

http://www.cmake.org/Wiki/CMake#Tutorials

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Convenience lib vs static library

[Óscar Fuentes]

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 systems (32 bit don't need
> -fPIC). However on some systems this is not supported at all, i.e. the
> linker simply doesn't support creating a shared library from static libs. I
> think one of those systems is windows, or rather MSVC. 

You can use a .def file on MSVC for telling the linker what to export
while creating the dll file.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Convenience lib vs static library

[Óscar Fuentes]

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.

The view can be limited and the terminology debatable, but the mentioned
usage of the convenience library is not wrong.

[snip]

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Convenience lib vs static library

[Óscar Fuentes]

"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 executable as any other object file. A static
library does not have this quality: the linker picks the library's
contents only if there is something elsewhere that requires it (i.e. a
reference to a symbol defined on some object file contained on the
library).

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Avoid nested cmake invocation taking parent's info.

[Óscar Fuentes]

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 or
>> > Environment one?
>>
>> When cmake is invoked with -DCMAKE_TOOLCHAIN_FILE=foo, the nested cmake
>> runs as invoked with this definition as well. It takes config-assigned
>> variables from the parent cmake, too. 
>
> I don't see how this should happen. Do you cross-compile in-source ?

No.

> The the second cmake would see the CMakeCache.txt from the cross compile.
> In that case: don't build in-source.
> If this is not the reason, please post a small example project so I can see 
> what's going on.

I'll put this on my TODO and create a bug report.

For now, I translated the cmake invocation to build time and it works.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to associate a command with a auto-generated target?

[Óscar Fuentes]

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 ADDITIONAL_CLEAN_FILES directory property is not powerful enough 
> for you ?

I guess you mean ADDITIONAL_MAKE_CLEAN_FILES. That was not what you
proposed on your previous message :-)

For this case, where a directory must be deleted together with all its
contents, it works.

Thank you, Alex.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to associate a command with a auto-generated target?

[Óscar Fuentes]

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-special-clean, do what you need, and also execute something like 
> ${CMAKE_MAKE_COMMAND}  clean

Sadly, this is not acceptable. People complain about having to learn
cmake and I want to avoid giving them a reason for complaining about
having to learn project-specific ways of doing standard things.

BTW, CMAKE_MAKE_COMMAND is not listed on --help-variables. You mean
CMAKE_BUILD_TOOL, don't you?

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to associate a command with a auto-generated target?

[Óscar Fuentes]

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

Re: [CMake] Avoid nested cmake invocation taking parent's info.

[Óscar Fuentes]

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?

When cmake is invoked with -DCMAKE_TOOLCHAIN_FILE=foo, the nested cmake
runs as invoked with this definition as well. It takes config-assigned
variables from the parent cmake, too. For instance, while
cross-compiling from Linux to Windows/MinGW, the parent cmake correctly
sets HAVE_WINDOWS_H, but the child cmake sets it too, and so on.

[snip]

> May be it would be possible to "reset" the cross-compile
> setup using appropriate CMAKE_TOOLCHAIN_FILE?
>
> Or you may reverse your scheme,
> Always run a "native" build for building native tool
> and make the native build invoke the Cross build using
>
> EXECUTE_PROCESS(
>  COMMAND ${CMAKE_COMMAND} CMAKE_TOOLCHAIN_FILE=
> ...
> )

Both suggestions seems good, but the idea is to lessen the burden on the
users and make things as simple as possible for them. Both methods
require specific instructions for this project that goes away from the
usual cmake practice and the work they save is negligible.

After some experimentation, using -UCMAKE_TOOLCHAIN_FILE on the
invocation of the nested cmake *sometimes* produces the right
thing. This sequence of commands does the trick:

work $ cmake -DCMAKE_TOOLCHAIN_FILE=mytoolchainfile path/to/source

# the above configures and generates the native build on the `native'
# subdirectory. The native build inherits the variables from the parent
# one.

work $ rm -R -f native/  # Delete the native build dir

# we re-execute cmake:

work $ cmake -DCMAKE_TOOLCHAIN_FILE=mytoolchainfile path/to/source

Now, the native build is correctly configured. On this last invocation
the configure phase for the cross-compile build is skipped, because it
is cached from the previous build. However, the native configure is
re-executed because we deleted it.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Avoid nested cmake invocation taking parent's info.

[Óscar Fuentes]

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_NATIVE_TG_DIR}
 )

where CX_NATIVE_TG_DIR is a new directory where the native build is
performed. Later,

  add_custom_command(OUTPUT ${LLVM_TABLEGEN}
COMMAND ${CMAKE_BUILD_TOOL} -C ${CX_NATIVE_TG_DIR}/utils/TableGen
COMMENT "Building native TableGen...")
  add_custom_target(NativeTableGen DEPENDS ${LLVM_TABLEGEN})

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.

How can this be avoided? I want the nested cmake to work as if the
enclosing cmake didn't existed.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Omitted dependencies.

[Óscar Fuentes]

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. What's the file where cmake stores header
file dependencies?

Using 2.6.1 on Linux with Unix makefiles.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Knowing the name of the linker.

[Óscar Fuentes]

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 not the linker
>> command name itself.
>
> Does CMAKE_LINKER have what you want ?

Yes, thank you.

It is not mentioned on --help-variables. I'm using 2.6.1.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Knowing the name of the linker.

[Óscar Fuentes]

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

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Generated file and parallel build.

[Óscar Fuentes]

Óscar Fuentes <[EMAIL PROTECTED]> writes:

>> macro(add_llvm_library name)
>>   add_library(${name} ${ARGN})
>>   add_dependencies(${name} ${LLVM_SOURCE_COMMON_DEPENDS})
>>   
>> endmacro()
>
> This doesn't work.

My wrong. This works.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Generated file and parallel build.

[Óscar Fuentes]

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 inside a macro:
>> 
>> macro(add_llvm_library name)
>>   if( LLVM_SOURCE_COMMON_DEPENDS )
>> set_source_files_properties( ${ARGN}
>>   PROPERTIES OBJECT_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS}
>>   )
>>   endif( LLVM_SOURCE_COMMON_DEPENDS )
>>   add_library( ${name} ${ARGN} )
>> 
>> 
>> where LLVM_SOURCE_COMMON_DEPENDS contains the name of the custom target
>> that is used to trigger the custom command that generates the file:
>
> You're mixing up file-level dependencies with target-level dependencies.
>  The OBJECT_DEPENDS property only specifies file-level dependencies.  I
> see its documentation is lacking.  I'll commit improved documentation
> for it.  The add_dependencies command is used to create extra
> inter-target dependencies:
>
> macro(add_llvm_library name)
>   add_library(${name} ${ARGN})
>   add_dependencies(${name} ${LLVM_SOURCE_COMMON_DEPENDS})
>   
> endmacro()

This doesn't work. The generation of the header file must be completed
before compiling the library's source files, and add_dependencies is not
for this. If my understanding is right, add_dependencies means that the
targets listed on LLVM_SOURCE_COMMON_DEPENDS must be built before
invoking `ar', but doesn't mean that the compilation of the library's
source files must be delayed until the targets listed on
add_dependencies are completed.

> Just make sure the LLVM_SOURCE_COMMON_DEPENDS variable contains only
> target names and not files.
>
>> add_custom_command(OUTPUT ${path_to_intrinsics_gen}
>>   COMMAND tblgen -gen-intrinsic ... -o ${path_to_intrinsics_gen}
>>   DEPENDS tblgen
>>   COMMENT "Building intrinsics.gen...")
>> 
>> add_custom_target(intrinsics_gen ALL
>>   DEPENDS ${path_to_intrinsics_gen})
>> 
>> set(LLVM_SOURCE_COMMON_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS} intrinsics_gen )
>
> This is correct.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Generated file and parallel build.

[Óscar Fuentes]

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}
  PROPERTIES OBJECT_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS}
  )
  endif( LLVM_SOURCE_COMMON_DEPENDS )
  add_library( ${name} ${ARGN} )


where LLVM_SOURCE_COMMON_DEPENDS contains the name of the custom target
that is used to trigger the custom command that generates the file:

add_custom_command(OUTPUT ${path_to_intrinsics_gen}
  COMMAND tblgen -gen-intrinsic ... -o ${path_to_intrinsics_gen}
  DEPENDS tblgen
  COMMENT "Building intrinsics.gen...")

add_custom_target(intrinsics_gen ALL
  DEPENDS ${path_to_intrinsics_gen})

set(LLVM_SOURCE_COMMON_DEPENDS ${LLVM_SOURCE_COMMON_DEPENDS} intrinsics_gen )

This doesn't work. The parallel build tries to compile the sources
that depends on intrinsics_gen before executing the custom command. I've
tried to use ${path_to_intrinsics_gen} (that is, the custom command
output) instead of intrinsics_gen, to no avail.

What I'm doing wrong?

CMake 2.6.1 -G "Unix Makefiles".

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [CMAKE]make uninstall

[Óscar Fuentes]

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
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake erases targets at regeneration.

[Óscar Fuentes]

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:

macro(add_partially_linked_object lib)
  if( MSVC )
add_llvm_library( ${lib} ${ARGN})
  else( MSVC )
set(pll ${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}/${lib}.o)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib)
add_library( ${lib}_tmp STATIC ${ARGN})
add_custom_command(OUTPUT ${pll}
  MESSAGE "Building ${lib}.o..."
  DEPENDS ${lib}_tmp
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/temp_lib
  COMMAND echo ${lib}
  COMMAND echo ${pll}
  COMMAND ar x 
${CMAKE_STATIC_LIBRARY_PREFIX}${lib}_tmp${CMAKE_STATIC_LIBRARY_SUFFIX}
  COMMAND ld -r *${CMAKE_CXX_OUTPUT_EXTENSION} -o ${pll}
  COMMAND rm -f *${CMAKE_CXX_OUTPUT_EXTENSION}
  )
add_custom_target(${lib} ALL DEPENDS ${pll})
set( llvm_libs ${llvm_libs} ${pll} PARENT_SCOPE)
  endif( MSVC )
endmacro(add_partially_linked_object lib)

where `add_llvm_library' is not relevant, as we are working with
MSYS/g++ (anyways, it is just a wrapper for add_library). The macro is
used as:

add_partially_linked_object(LLVMInterpreter
  Execution.cpp
  ExternalFunctions.cpp
  Interpreter.cpp
  )

and creates lib/LLVMInterpreter.o

There are three files that are created with this method. Two are deleted
after the regeneration and one not. This one depends on a custom target.

I can post the sources upon request.

The problem does not happen on Linux ("Unix Makefiles").

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Building system triplet

[Óscar Fuentes]

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

Re: [CMake] Re-executing CMake from the Makefile.

[Óscar Fuentes]

[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 available, the
>> executables are ignored.
>> 
>> $ make # this builds the libs and llvm-config and stops.
>> 
>> $ make # This implicitly invokes cmake, which now can use llvm-config for
>> determining dependencies and build the executables.
>> 
>> It would be a good thing if the second `make' were not necessary.
>
> You can do this in one build by splitting it into two projects in terms
> of CMakeLists.txt file layout. [snip]

What I'm doing now is to invoke cmake from the command that builds the
script:

add_custom_command(OUTPUT ${LLVM_CONFIG}
  COMMAND <... builds the script ...>
  COMMAND cd ${LLVM_BINARY_DIR} &&
${CMAKE_COMMAND} -U HAVE_LLVM_CONFIG ${LLVM_MAIN_SRC_DIR}
  DEPENDS ...
)

where HAVE_LLVM_CONFIG is the variable that says if the script exists.

This works, at least on MSYS/MinGW, and it is simpler than splitting the
project.

> I can provide more help if you need it.

This is very much appreciated, Brad. I have experience dealing with you
long time ago with gcc-xml and seeing your name related to CMake was one
of the main reasons for choosing it.

Thanks,

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re-executing CMake from the Makefile.

[Óscar Fuentes]

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 executables just provide names
>> of components, the script maps this names to actual libraries and
>> returns the full list of needed libraries on the correct order for using
>> it on the link command.
>> 
>> If you know an elegant way to handle this with CMake, I'll like to hear
>> it.
>> 
>> BTW, this is for the Low Level Virtual Machine (LLVM) www.llvm.org
>
> I assume you're refering to this script:
>
>   http://llvm.org/svn/llvm-project/llvm/trunk/utils/GenLibDeps.pl

This analyzes the dependencies. This is appended to llvm-config:

http://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-config/llvm-config.in.in

This script is executed within the link command (with shell backquotes)
to obtain the libraries for certain set of components:

$ llvm-config -libs jit native interpreter
$ ./bin/llvm-config --libs jit native interpreter

/d/dev/lib/llvm-git/mingw/lib/LLVMInterpreter.o
/d/dev/lib/llvm-git/mingw/lib/LLVMX86.o -lLLVMLinker -lLLVMArchive
/d/dev/lib/llvm-git/mingw/lib/LLVMJIT.o -lLLVMExecutionEngine -lLLVMipo
-lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils
-lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMBitReader -lLLVMVMCore
-lLLVMSupport -lLLVMSystem

> It seems to rely on certain output from "nm".  Does this work with any
> windows compilers?

No. Windows linkers (like MSVC's) are much simpler to handle. They are
not sensitive to library specification order on the command
line. Neither there is a need for partial linking. At least until shared
libraries are supported on MSVC, just passing all libraries on the
command line is enough.

> Inferring dependencies among already-built static
> libraries is not a design goal for CMake as it tries not to depend on
> any low-level details of native tools.  However, given an explicit
> list of static libs and their *direct* dependencies, CMake will chain
> them automatically and handle the circular cases.

It seems there are Unix linkers that can't handle circular cases. This
is why some libraries are partially linked as object files.

> I think in the long run LLVM should just explicitly declare its
> dependencies.  They can't be *that* complicated.

LLVM is made of components. At configure time, you choose the components
you want. This affects what libraries are built and how they depends one
on another. It affects the libraries every executable depend on,
too. The job of `llmv-config' is hiding all this complexity when you
need to link an executable with the LLVM libraries.

> See below for output I got from building llvm.  Would it really be so
> bad to list that by hand?  It's 18 lines that could be distributed
> throughout each library's build files.  The executables already list
> their direct dependencies explicitly.

I'm afraid that listing library dependencies by hand would be seen as a
unaceptable regression wrt the current build system. However, I'm
thinking on a two-phase build, something like this:

$ cmake -G "Unix Makefiles" # as llvm-config is not available, the
executables are ignored.

$ make # this builds the libs and llvm-config and stops.

$ make # This implicitly invokes cmake, which now can use llvm-config for
determining dependencies and build the executables.

It would be a good thing if the second `make' were not necessary.

Thanks for looking into this, Brad.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re-executing CMake from the Makefile.

[Óscar Fuentes]

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/file/output, that should stop make from running.

Okay.

>> All this is because /my/file/input actually is an script that is used
>> for determining which libraries the executables depends on. The current
>> build system builds the libraries, then the script and finally the
>> executables. As initially it is impossible for `cmake' to stablish
>> dependencies between libraries and executables, I wish the build to stop
>> or restart once the script is built and re-execute cmake so it can use
>> the script for inquiring what the dependencies are, re-generate the
>> makefiles and continue the build.
>>
>
> Why does the script need to be constructed at make time?  Seems like
> you could push a bit more of the work into the script itself and all
> should be good.

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 executables just provide names
of components, the script maps this names to actual libraries and
returns the full list of needed libraries on the correct order for using
it on the link command.

If you know an elegant way to handle this with CMake, I'll like to hear
it.

BTW, this is for the Low Level Virtual Machine (LLVM) www.llvm.org

Thanks, Bill.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Re-executing CMake from the Makefile.

[Óscar Fuentes]

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) with an arbitrary file?
>>
>> I need to re-execute `cmake' whenever certain file changes. I wonder if
>> is possible to do this from `make' itself, so the user does not need to
>> remember that he must execute `cmake' first.
>>
> If the file you depend on is part of the input to cmake then cmake
> will do that automatically.  You could use the configure_file command
> to do this.  If you did something like this:
>
>  configure_file(/my/file/input dummyout)
>
> Then when ever /my/file/input changed cmake would re-run at make time.

Will this work if /my/file/input is the output of some intermediate
`make' execution?

I mean:

$ make  # invoke make, which may modify /my/file/input at some point

Will `make' invoke `cmake' on the fly and keep running with the new
makefiles regenerated by `cmake'?

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.

All this is because /my/file/input actually is an script that is used
for determining which libraries the executables depends on. The current
build system builds the libraries, then the script and finally the
executables. As initially it is impossible for `cmake' to stablish
dependencies between libraries and executables, I wish the build to stop
or restart once the script is built and re-execute cmake so it can use
the script for inquiring what the dependencies are, re-generate the
makefiles and continue the build.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

Ó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 scripts.
>
> It is working with 2.6.1 and MSYS Makefiles. Here you are doing
> something like this:
>
> cd ${CMAKE_CURRENT_BINARY_DIR} && /path/to/g++.exe ...args for linking...

It doesn't work on Linux (Debian Etch x86) Unix Makefiles.

Too bad CMake is not consistent on this. Not having the possibility of
customising the command on make-time seems a serious limitation.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Re-executing CMake from the Makefile.

[Óscar Fuentes]

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 this from `make' itself, so the user does not need to
remember that he must execute `cmake' first.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

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 intended for POSIX platforms, GNU
>> toolchains. As far as cmake does not mess too much with the contents
>> passed to target_link_libraries, it should be fine.
>>
> Actually, CMake does not guarantee a shell at all for the link line,
> so back tick stuff make break even on a POSIX platform.  Why does this
> need to be run at build time?

Please see my response to Mike Jackson above.

> I don't even think this will work with cmake 2.6.0, because we use
> link scripts.

It is working with 2.6.1 and MSYS Makefiles. Here you are doing
something like this:

cd ${CMAKE_CURRENT_BINARY_DIR} && /path/to/g++.exe ...args for linking...

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

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
> for you.
>   Maybe you could give some more detail about your use case?

There are several libraries with cyclic dependencies. This forces the
use of `partial linking' (see my message a few days ago). There are a
number of executables, each with different library requirements. Due to
the complexity of the libraries, the executable's CMakeLists.txt (or,
until now, the hand-made Makefile's) does not mention the library names
explicitly. It mentions names of components and a script returns the
libraries and object files (partially linked libs, see above) in the
correct order for the components requested.

A typical link command is like this:

g++ ..flags... object-files... `script component1 component2`

the script returns something like:

-lmylib1 -lmylib2

There is another script that determines library interdependencies (by
analyzing the output of `nm' on the libraries) and builds the first
mentioned script. Of course, this must be performed after the libraries
are built.

So CMake can not determine dependencies because those are unknown until
the libraries are built and cmake time has ended long time ago.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

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 this is to use execute_process and
> collect the output at cmake time, and then use target_link_libraries.

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 intended for POSIX platforms, GNU
toolchains. As far as cmake does not mess too much with the contents
passed to target_link_libraries, it should be fine.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

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 this is to use execute_process and
> collect the output at cmake time, and then use target_link_libraries.

Thanks for the warning, but I need the output at make invokation time,
unless there is a way to create a dependency such that cmake runs and
the makefile is regenerated when the script changes.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invoking an script from the link command.

[Óscar Fuentes]

Ó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

[CMake] Invoking an script from the link command.

[Óscar Fuentes]

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 backquoted script invocation on the LINK_FLAGS property, but its
contents appears before the object-files part and so it is not
effective.

My second try was target_link_libraries:

target_link_libraries(myexe `/path/to/script arg1 arg2`)

but this results on:

g++ ... `/path/to/script -larg1 -larg2`

Suggestions appreciated.

-- 
Oscar

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake