Re: [CMake] building cmake without the bootstrap step

[René J . V . Bertin]

Never mind, this tweak to the bootstrap script should take care of anything not 
directly obvious. Could do with an automated test of the installed version but 
the accepted version range is so large that doesn't seem to be the trouble.

```
if [ -x ${cmake_prefix_dir}/bin/cmake ] ;then
  # use the existing cmake that we'll be replacing.
  ln -s ${cmake_prefix_dir}/bin/cmake ${cmake_bootstrap_dir}/cmake
else
  # Run make to build bootstrap cmake
  if [ "x${cmake_parallel_make}" != "x" ]; then
${cmake_make_processor} ${cmake_make_flags}
  else
${cmake_make_processor}
  fi
  RES=$?
  if [ "${RES}" -ne "0" ]; then
cmake_error 9 "Problem while running ${cmake_make_processor}"
  fi
fi
cd "${cmake_binary_dir}"
```

R
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] building cmake without the bootstrap step

[René J . V . Bertin]

On Thursday December 12 2019 09:36:03 Kyle Edwards wrote:

>If you want to skip bootstrapping, you can use a pre-existing CMake
>binary for your system to build the new CMake.
>
>This mailing list is deprecated. Please head over to Discourse for
>further discussion:

OK, thanks. To finish things up here, there is thus nothing in the arguments to 
the bootstrap script that is crucial and cannot be set via a preexisting cmake 
command?

R.
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] building cmake without the bootstrap step

[René J . V . Bertin]

Hi,

If I understand correctly, configuring CMake for building means bootstrapping a 
basic version of itself which is then run on the included CMakeLists.txt file. 
That takes a lot of time (comparatively) which begs the question if there's a 
more-of-less official way to skip the bootstrap and just use the installed 
cmake binary?

Thanks,
René
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] cmake and high-dpi support on Mac

[René J . V . Bertin]

Hi,

CMake had hardcoded default support for high-dpi screens in the applications it 
generated for Apple's desktop OS at some point, but that was removed very 
quickly in 286c75f7f034c5fdcd43bcb755da74d09c809642.

It is my understanding that you don't actually need to set the high-dpi key 
explicitly, but that it defaults to on for the desktop OS. IOW, it's enough to 
set the NSPrincipalClass property to NSApplication.

I cannot check this myself, and I have no idea if and how NSPrincipalClass can 
be set for Apple's other OS variants.
But maybe one could use this property in a minimal-change change to enable 
high-dpi support automatically in applications that do not provide their own 
Info.plist: add this to the bundle plist template:

+   NSPrincipalClass
+   <${MACOSX_BUNDLE_PRINCIPALCLASS}/>

If the target OS is known when the MACOSX_BUNDLE_* variables get their default, 
MACOSX_BUNDLE_PRINCIPALCLASS could default to whatever class is appropriate for 
the target OS, otherwise it would just be set to NSApplication (and users 
targetting other OS variants would have to set the property explicitly, which 
is still less cumbersome than providing a custom template).

Thoughts please?
Thanks,
R.


-- 

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

[CMake] CMAKE_AR/NM/RANLIB require full path?!

[René J . V . Bertin]

Hi,

I just got some build failures when changes to my build scripts led to 
configuring with -DCMAKE_AR=ar (RANLIB=ranlib, etc).

The documentation isn't explicit on what these parameters expect so I assumed 
that it should be fine to set them to a command name, as with 
CMAKE__COMPILER.

Wrong! CMake will apparently prepend CMAKE_BINARY_DIR to these commands.

If this is intentional, why isn't it documented in the CMAKE_AR (etc) 
description?

Thanks,

R.
-- 

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

Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

[René J . V . Bertin]

Sylvain Joubert wrote:

> My use case is for static analysis builds. For example, my CI setup has
> multiple of them including cppcheck, clang-tidy and iwyu through the
> CMake integration. And since I'd like to keep separate builds for each
> of them this requires 3 full build whose results I don't really care.

Are you thinking of tools that are invoked instead of the compiler, like clazy-
standalone? I thought about mentioning a potential interest of my idea for 
using 
such tools (but forgot in the end).

Specific support for -fsyntax-only may not be relevant for those tools, but a 
build mode where the final step of each build product is not taken would 
probably 
be useful there, indeed. Such a mode might even create an empty file with the 
intended name, so that there's something to refer to later during a build.

I've been considering to write a little wrapper one could "inject" using 
CMAKE__COMPILER_LAUNCHER but there is no equivalent for the final product 
generation step (linker, librarian).

> 
> So if we can achieve a light build mode, that would be great. In my case
> I could completely deactivate the build part including the syntax
> checking since that's done by the static analysis tools anyway.

You'd get that by setting your analysis tool as the compiler.

> Anyhow, we can't deactivate all the build. As you said auto-generated
> content, custom targets,... would need to stay.

And besides, cmake's goal is to create files with which one can build projects. 
Generating something that doesn't attempt to build at all could well require a 
lot more implementation effort than pretending the linker/librarian step always 
succeeds.

FWIW, I notice that the link step now takes the form

cmake -E cmake_link_script CMakeFiles/.dir/link.txt

IOW there are 2 levels where linker errors due to missing objects can be 
intercepted: in the link.txt script, and in cmake itself.

R.

-- 

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

[CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)

[René J . V . Bertin]

Hi,

Apologies, longish post ahead. I've tried to present my idea and the thought 
train leading up to it as succinctly as possible. Hope I at least strike a 
chord!

Clang and GCC have long supported an option that makes them stop after the 
syntax-verification stage: -fsyntax-only . This has the advantage (see below) 
that it's much faster than a regular build and that no output is generated. The 
absent output is also a problem and the reason I'm posting about it here:
- compiler checking fails because of the missing output.
- link and archive (static lib) creation fail because of missing files.

The first problem should not be hard to fix (filter out -fsyntax-only from the 
arguments used to check the compiler). The 2nd problem can be addressed by 
ignoring the exit code from linking and archiving commands (possible with make, 
presumably with ninja too).

Would it be feasible to implement "something" that makes it possible to run a 
full pure-syntax-checking "build", either as a special target or as a separate 
mode of operation or CMAKE_BUILD_TYPE?

I think this could be useful in general esp. with larger projects, allowing to 
check "quickly" if a change (triggering a full rebuild) breaks something. 
QtWebKit would be an appropriate example: it uses a central header to set the 
configuration preprocessor tokens so toggling even one of these switches causes 
*everything* to be rebuilt.

Some more observations which outline a context where cmake-level support for a 
pure syntax-checking run would be beneficial (also the context that made me 
remember the -fsyntax-only option):

- a number of IDEs (can) use CMake as the basis for project definition.
- They also provide parsing facilities that also use information from cmake to 
control the parser.
- KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, 
which means KDE projects depend on auto-generation of files which need to be 
included in C++ code.
- Parsing or even syntax-checking won't work to at least some degree without 
those auto-generated files.
- opening a project in an IDE is not always done with the intention to build 
it; in absence of such an intention one usually does expect to be able to rely 
on parsing and syntax checking.
- Auto-generation of Qt's automatic content occurs during a full build, when 
needed.

That last observation is the big bottleneck; a full build can be very costly. 
If there were a dedicated target to generate just all automatic content one 
could just build that target and there would be no issue left. Whether or not 
this is impossible is unclear, and at least not entirely a CMake issue.

Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable 
solution.

R.

-- 

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

[CMake] SOVERSION and Mac library id in shared library made from assembly files

[René J . V . Bertin]

Hi,

I have a little project that creates a shared library from a pair of assembly 
files. I've been trying to follow examples such that the generated library

- has versioning (libFastCompression.1.dylib on Mac or libFastCompression.so.1 
on Linux)
- has the full path as its ID on Mac


I get this in the projects I used as example, but not in this particular 
project.

Am I overlooking/forgetting something, or is what I'm looking for not 
implemented/supported for libraries built exclusively from assembly files?

The project: github.com/RJVB/lzvn

Thanks!

René
-- 

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

Re: [CMake] losing CMakeCache.txt after changing the compiler...

[René J . V . Bertin]

Marc CHEVRIER wrote:

> If you have multiple compilers or even multiple versions of a compiler, by
> managing carefully environment variables (i.e. PATH variable for example)
> by using some bash functions, you can easily ensure to use always the
> correct compiler for each build environment.

That just shouldn't be necessary: to do this properly (in a way to helps 
avoiding simple mistakes like running cmake with 1 env. setting and then make 
with a different setting) requires writing something on top of cmake.

Not that I already have something like that, but did I say it shouldn't be 
necessary?

-- 

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

Re: [CMake] losing CMakeCache.txt after changing the compiler...

[René J . V . Bertin]

Marc CHEVRIER wrote:

> You can easily avoid this bad experience by using different builds
> environments : one per compiler !


You mean one build directory per compiler? That can be very disk-expensive, and 
it doesn't solve the issue (e.g. you clone an environment and then change the 
compiler - why would that cause certain cached variables to be reset that don't 
need to be reset).

Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto-
generation applications use a mix of hardcoded absolute and relative paths that 
can easily go wrong when you update something that invalidates certain paths.

Or when you access your build directory in different ways. This is a bit of a 
different issue, but suppose you have directories:

/a/b/c/d/e/f/projectA/work/source
/a/b/c/d/e/f/projectA/work/build

and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA

Depending on shell and OS you may get surprises when you do things like

%> cd $HOME/projects/
%> (cd projectA/work/build ; cmake ../source)
%> (cd /a/b/c/d/e/f/projectA/work/build ; make)

Qt's auto-generated relative paths (in step 2) will be invalid in step 3 if no 
path normalisation occurs, because of the different number of levels between 
the 
2 access paths to the same working directory. Linux suffers from this, not the 
Mac OS.

This is a cmake issue only insofar as cmake could prevent it by normalising the 
working dir always (make should probably do the same).

R.

-- 

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

[CMake] losing CMakeCache.txt after changing the compiler...

[René J . V . Bertin]

Hi,

This happened once too often for me: I apply successive tweaks to a CMakeCache 
file, reinvoke make (or ninja) and then at some point lose everything because I 
forgot that changing the compiler is a "lethal" operation.

Why does cmake have to throw away the entire cache file when something changes 
in the compiler path? That seems like a cheap way to implement a "let's keep 
track of which cached settings depend on the choice of compiler". At the least 
it wouldn't be much less cheap to rename CMakeCache.txt to CMakeCache.bak 
instead of deleting it.

And FWIW, this is also a situation in which storing the exact CMake invocation 
in a comment at the top of the cache file could be useful...

R.
-- 

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

[cmake-developers] Suggestion: include deployment target and sysroot path in feature_summary on Mac

[René J . V . Bertin]

Hi,

A thought:

I know CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_SYSROOT are intended mainly to 
be used by users building a project as opposed to by the build system itself, 
but it could still be informative to include these settings in the "verbose" 
feature_summary() print-out.

I.e. something like

if(CMAKE_OSX_DEPLOYMENT_TARGET)
message(STATUS "OS X Deployment target: ${CMAKE_OSX_DEPLOYMENT_TARGET}")
endif()
if(CMAKE_OSX_SYSROOT)
message(STATUS "OS X SDK sysroot: ${CMAKE_OSX_SYSROOT}")
endif()

Regards,
R.B.

-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] cmake not always replacing symlinks in the path used to access a build.dir?!

[René J . V . Bertin]

WTH, apparently this can even happen without regeneration (that I know of, at 
least):

%> CD kdevld-lnx-work/build/plugins/ wmake --MP -w
### 
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins
### /home/bertin/script/wmake --MP -w
### Mon Sep 18 11:06:15 CEST 2017

make: Entering directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins'
cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && 
/opt/local/bin/cmake 
-H/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5
 -B/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build 
--check-build-system CMakeFiles/Makefile.cmake 0
cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && 
/opt/local/bin/cmake -E cmake_progress_start 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/CMakeFiles 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/plugins/CMakeFiles/progress.marks
cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && make -f 
CMakeFiles/Makefile2 plugins/all
make[1]: Entering directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build'
make -f 
kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make
 kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/depend
make[2]: Entering directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build'
cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && 
/opt/local/bin/cmake -E cmake_depends "Unix Makefiles" 
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5
 
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces
 /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces
 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/DependInfo.cmake
 --color=
Scanning dependencies of target KDevPlatformInterfaces_autogen
make[2]: Leaving directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build'
make -f 
kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make
 kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build
make[2]: Entering directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build'
[  0%] Automatic MOC for target KDevPlatformInterfaces
cd 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces
 && /opt/local/bin/cmake -E cmake_autogen 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir
 MacPorts
Generating MOC predefs moc_predefs.h
Generating MOC source include/moc_iplugin.cpp
Generating MOC source EWIEGA46WW/moc_configpage.cpp
Generating MOC source EWIEGA46WW/moc_iassistant.cpp
Generating MOC source EWIEGA46WW/moc_icompletionsettings.cpp
Generating MOC source EWIEGA46WW/moc_icore.cpp
Generating MOC source EWIEGA46WW/moc_idebugcontroller.cpp
Generating MOC source EWIEGA46WW/moc_idocumentation.cpp
Generating MOC source EWIEGA46WW/moc_idocumentationcontroller.cpp
Generating MOC source EWIEGA46WW/moc_idocumentcontroller.cpp
Generating MOC source EWIEGA46WW/moc_ilanguagecontroller.cpp
Generating MOC source EWIEGA46WW/moc_ipartcontroller.cpp
Generating MOC source EWIEGA46WW/moc_iplugincontroller.cpp
Generating MOC source EWIEGA46WW/moc_iproject.cpp
Generating MOC source EWIEGA46WW/moc_iprojectcontroller.cpp
Generating MOC source EWIEGA46WW/moc_iprojectprovider.cpp
Generating MOC source EWIEGA46WW/moc_iruncontroller.cpp
Generating MOC source EWIEGA46WW/moc_iruntime.cpp
Generating MOC source EWIEGA46WW/moc_iruntimecontroller.cpp
Generating MOC source EWIEGA46WW/moc_iselectioncontroller.cpp
Generating MOC source EWIEGA46WW/moc_isession.cpp
Generating MOC source EWIEGA46WW/moc_isourceformatter.cpp
Generating MOC source EWIEGA46WW/moc_isourceformattercontroller.cpp
Generating MOC source EWIEGA46WW/moc_itestcontroller.cpp
Generating MOC source EWIEGA46WW/moc_launchconfigurationpage.cpp
Generating MOC source EWIEGA46WW/moc_launchconfigurationtype.cpp
make[2]: Leaving directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build'
[  0%] Built target KDevPlatformInterfaces_autogen
make -f 
kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/build.make 
kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/depend
make[2]: Entering directory 

[CMake] cmake not always replacing symlinks in the path used to access a build.dir?!

[René J . V . Bertin]

Hi,

I'm seeing a weird issue with a large project: KDevelop. It was reorganised 
recently but I think that's what exposes the issue, rather than causing it.
My workflow puts both source and out-of-source build directories rather deep in 
a dedicated "playground"; for convenience I create symlinks to the parent of 
both directories in one of my own work directories under my $HOME:

%> ls -l kdevd-lnx-work
lrwxrwxrwx 1 bertin bertin 92 Sep  5 15:18 kdevld-lnx-work -> 
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work

As long as I chdir directly into that "hidden" build.dir, invoke cmake and then 
make from there things are fine. Problems occur though when I change something 
in one of the project's CMakeLists.txt files, chdir into the build.dir via the 
symlink and then issue a make without running cmake by hand.

Consider the example below where I tried to do partial rebuild (something 
that's always worked reliably for me, a feature I really appreciate with 
cmake!). Evidently make is being executed in the actual directory, as shown by 
the output from `pwd` just underneath the `CD` line. Somewhere during the 
snipped part (which I don't have anymore) cmake was called automaticallyand 
that's where the symlink must have found its way into the 
Notice how the failing build of iplugin.cpp uses search paths that include the 
link that don't work with the relative include paths generated by the moc 
compiler. 

How can happen, for all I can tell cmake has no way of knowing about the 
symlink?!
FWIW, it's not something I can reproduce easily.

%> where CD
CD is aliased to (cd  !:^ ; !:2*)
%> CD kdevld-lnx-work/build/plugins/ wmake
### now in 
/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins
### make -w
### Sun Sep 17 20:32:06 CEST 2017
make: Entering directory 
`/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins'

[  0%] Building CXX object 
kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/iplugin.cpp.o
cd 
/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces
 && /opt/local/bin/ccache /opt/local/bin/clang++-mp-4.0  -DKCOREADDONS_LIB 
-DKDevPlatformInterfaces_EXPORTS -DQT_CORE_LIB -DQT_DBUS_LIB 
-DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS 
-DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER 
-DQT_WIDGETS_LIB -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"kdevplatform\" 
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces
 
-I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces
 
-I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/include
 
-I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5
 -I
 /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build 
-I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform
 -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform 
-isystem /opt/local/include/KF5/KParts -isystem /opt/local/include/KF5 -isystem 
/opt/local/include/KF5/KIOWidgets -isystem /opt/local/include/KF5/KIOCore 
-isystem /opt/local/include/KF5/KCoreAddons -isystem /opt/local/include/qt5 
-isystem /opt/local/include/qt5/QtCore -isystem 
/opt/local/share/qt5/mkspecs/linux-g++-64 -isystem 
/opt/local/include/KF5/KService -isystem /opt/local/include/KF5/KConfigCore 
-isystem /opt/local/include/KF5/KJobWidgets -isystem 
/opt/local/include/qt5/QtWidgets -isystem /opt/local/include/qt5/QtGui -isystem 
/opt/local/include/qt5/QtNetwork -isystem /opt/local/include/KF5/KCompletion 
-isystem /opt/local/include/KF5/KWidgetsAddons -isystem 
/opt/local/include/KF5/KXmlGui -isystem /opt/local/include/qt5/QtDBu
 s -isystem /opt/local/include/qt5/QtXml -isystem 
/opt/local/include/KF5/KConfigWidgets -isystem /opt/local/include/KF5/KCodecs 
-isystem /opt/local/include/KF5/KConfigGui -isystem 
/opt/local/include/KF5/KAuth -isystem /opt/local/include/KF5/KTextWidgets 
-isystem /opt/local/include/KF5/SonnetUi -isystem /opt/local/include/KF5/KI18n 
-isystem /opt/local/include/KF5/KTextEditor  -Ofast -g -DNDEBUG -std=c++11 -m64 
-std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS 
-Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time 
-fPIC -fvisibility=hidden -fvisibility-inlines-hidden   
-Wno-missing-field-initializers -Werror=undefined-bool-conversion 

Re: [CMake] setting/removing compiler flag (-g) for a single project directory

[René J . V . Bertin]

On Friday September 15 2017 16:51:24 Steven Velez wrote:

>Yeah... I didn't mean to respond personally... i didn't realize my client
>was doing that and not the list.

OK, replying back to the list then.

>What do you mean by "variables related to targets have global scope"?

I probably could have been a bit less vague. Defining a target in a 
subdirectory sets something that behaves like a global variable (pardon, 
constant :)), at least for libraries. That's the whole point of that common_dir 
subtree: it defines library targets which are then used for linking the plugin.

R.

>
>On Fri, Sep 15, 2017 at 3:44 PM, René J.V. Bertin 
>wrote:
>
>> On Friday September 15 2017 15:34:34 Steven Velez wrote:
>>
>> Logically that's what I'd expect, but then the variables related to
>> targets have global scope, variables set in a module directories too etc. I
>> preferred to ask, so thanks :)
>>
>> R.
>>
>> >All directories in cmake have their own scopes which are initialized by
>> the
>> >scope of the parent directory.
>> >
>> >So, if you set the variables you wish to set in CMakeLists.txt of
>> >common_libs, they should not influence the builds in the plugin directory,
>> >but will influence the builds in that directory and subdirectories.
>> >
>> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7.
>> html#cmake-language-variables
>> >
>> >For more info.
>> >
>> >Steven

-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] setting/removing compiler flag (-g) for a single project directory

[René J . V . Bertin]

Hi,

Is it possible to  set and/or remove compiler arguments on a project 
subdirectory that holds a tree with sources of a considerable number of build 
targets?

An example to make this more concrete: I have a project that contains

common_libs
plugins/foo
plugins/this_one

I'm just interested in building plugins/this_one and can do so by calling make 
&& make install/fast inside the build/plugins/this_one directory. All plugin 
dependencies are already installed (with debug info). The build/common_libs 
directory gets pretty big and is expensive to build, so ideally I would build 
everything in there with different flags, basically replacing -O3|-O2 with -Os 
and removing the -g option, possibly even running a strip before continuing the 
rest of the build.

I know one can do this kind of thing per target or even per file, but how does 
one do it on a directory basis? Do I have to cache the original CMAKE_C*_FLAGS 
value before modifying it in common_libs/CMakeLists.txt , and restore it before 
returning from that file? Or is there a more elegant method?

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Eric Noulard wrote:

> From the command line I doubt it.

Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works.

But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't 
affect the IMPORTED_LOCATION target property...


> Did you try to use ninja generator instead of make ?
> The no-op build is really faster with ninja.

I compared single full builds with ninja and make yesterday; with ninja it was 
actually (a bit) slower and required more resources (including a larger build 
directory). My main gripe with it is that you cannot simply launch a partial 
build from a subdirectory.

R

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Eric Noulard wrote:

> Thanks you for digging this.
> I totally ignored that "feature".

I guess most of us did, it's one of those things that usually works just fine 
but that when it breaks sends you on a nasty quest to figure out WTF is going 
on 
(IOW, makes you doubt yourself until you realise you just discovered a hidden 
feature).

I found this only because I searched the CMake source tree for LIBRARY_PATH to 
see where it does the rewriting. I would never have guessed to find the feature 
biting me under the concept "implicit directories".

> I you have a look at file:
> 
https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx
> 
> you may discovered (as I just did) that not all CMake supported systems
> kindly accept full path to library for linking...

CMake being a system that allows to describe how to build a project in a 
platform-agnostic way it could easily have handled those systems individually.

> I guess the author/contributor to this part of CMake may certainly explain
> that better than me.

Presumably, and I guess s/he might admit not having thought of (or tested) the 
kind of situation where rewriting breaks things.

Something you said in a mail that apparently didn't go to the list:

> OK, but I don't think CMake should "fight" the underlying compiler.

No. Clang may have a reason for the different way of handling LIBRARY_PATH 
which 
means you'd have to leave a possibility for it to work that way - maybe even by 
default. But in this case we're not fighting the compiler, we're trying to let 
it work another way that is just as supported.

> Looking the code is interesting because apparently what you need is to set
>  CMP0060 to NEW:
> 
> $ cmake --help-policy CMP0060
> CMP0060

Ah, great. I would probably have found that by myself, eventually.

> ---
> 
> Link libraries by full path even in implicit directories.
> 
> 
> The OLD behavior for this policy is to ask the linker to search for
> libraries whose full paths are known to be in implicit link directories.
> The NEW behavior for this policy is to link libraries by full path even
> if they are in implicit link directories.
> 
> This policy was introduced in CMake version 3.3.  Unlike most policies,
> CMake version 3.7.2 does *not* warn by default when this policy
> is not set and simply uses OLD behavior.  See documentation of the
> ``CMAKE_POLICY_WARNING_CMP0060``
> variable to control the warning.
> 
> 
> The thing I don't understand is that you use CMake 3.8.2 so you should get
> the new behavior.

Are you sure? I read from the description above that you have to set the policy 
explicitly.

Do you know if one can set policies like this from the commandline rather than 
through patching each toplevel CMakeLists.txt file? Or can it be set for just a 
subdirectory?

> However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
> set the CMP0060 to old.

Quite possible, I've run into naggles with that with another policy on Mac (25).
It's annoying that this happens with digikam which is a really cumbersome 
project (it takes ages just to run make just to confirm that everything has 
been 
built).

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Andreas Naumann wrote:

> cmake instrospects your compiler and asks for system directories.

Just stumbled across this documentation tidbit:

>>>
CMAKE__IMPLICIT_LINK_DIRECTORIES
--

Implicit linker search path detected for language .

Compilers typically pass directories containing language runtime
libraries and default library search paths when they invoke a linker.
These paths are implicit linker search directories for the compiler's
language.  CMake automatically detects these directories for each
language and reports the results in this variable.

When a library in one of these directories is given by full path to
:command:`target_link_libraries` CMake will generate the ``-l`` form on
link lines to ensure the linker searches its implicit directories for the
library.  Note that some toolchains read implicit directories from an
environment variable such as ``LIBRARY_PATH`` so keep its value consistent
when operating in a given build tree.
<<<

Note the
> CMake will generate the ``-l`` form on link lines to ensure the linker 
> searches its implicit directories

What's the point in doing that when a full path is given? Full path means 
searching isn't required. Full path (probably) means that the operator wants to 
ensure that a specific library is linked. Full path thus means that searching 
can even have counterproductive effects.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Eric Noulard wrote:

> AFAIK the explanation you gave. CMake does not seem to play with -l or -L
> options.

As Rolf said above, apparently it does.

> the FindPNG.cmake shipped with CMake does not do that either.

Indeed, it sets PNG_LIBRARY to the path of libpng, and PNG_LIBRARIES to the 2 
required libraries (libpng and libz), both with full path. There would be no 
problem if that data ended up in the linker command.

> Which version of CMake are you using?

3.8.2

> Which version of digikam are you trying to compile?

5.6.0

> Did you try to
> 
> message(STATUS "show me  PNG_LIBRARIES=${PNG_LIBRARIES}")

Yes, the variable contains the correct 2 paths.

> Now I'm lost. If the culprit is a clang feature/bugs then why did you
> suspect CMake in the frst place?

Because at the end of the day that doesn't matter : CMake must generate 
Makefiles that work, and thus has to work around known issues or peculiarities 
in the compilers it support. That could be through hardwired exceptions, but in 
this case could also be by providing a way to disable rewriting those library 
specifications.

Maybe there is, I haven't yet found any documentation whatsoever about the 
conditions under which CMake will (supposedly) replace a /path/to/libfoo.so 
libspec with -lfoo .

> Does the command line produced by the CMake generator you use (?makefile
> ?ninja ?) contains
> the full path to lib or -L + -l flags?

No. It contains -lpng -lz but no -L flag. See the more specific discussion in 
cmake-devel ("FindPNG.cmake doesn't return a LIBRARY_DIR variable").

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Rolf Eike Beer wrote:

>> It seems that clang handles that variable in a somewhat different manner
>> than GCC does. Even in a very simple call on the commandline (including the
>> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
>> libraries, where GCC puts it before the 1st -l option.
> 
> Welcome to the work of link_directories(). This is exactly the reason to avoid
> it: it always causes trouble.

digikam (that's the project we're talking about) doesn't use neither that nor 
target_link_directories. And if CMake simply used the libraries as found and 
specified in the target_link_libraries() call I wouldn't have run into problems 
either.

I did raise a flag on the clang ML though. But whether it's a clang bug or 
feature the fact remains that ideally one should be able to tell cmake exactly 
what to do, without it trying to outguess the operator.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] FindPNG.cmake doesn't return a LIBRARY_DIR variable

[René J . V . Bertin]

Rolf Eike Beer wrote:


> First, FindPNG.cmake doesn't care about pkg-config files, if that is bug

Yes, I noticed that after I wrote the remark about the pkg-config files, and 
didn't think to remove it (= I diagnosed the issue while writing the message).

> or feature depends on your personal things. CMake will detect the
> library using the full path (as it has done), and construct proper -L
> and -l from that. It doesn't happen here, which makes me suspect that
> you don't even link to ${PNG_LIBRARIES} or PNG::PNG (the latter being

>From the CMake file (digikam-5.6.0/core/app/CMakeLists.txt):

target_link_libraries(digikamcore
  PUBLIC

  Qt5::Core
  Qt5::Gui
  Qt5::Xml
  Qt5::Widgets
  Qt5::Sql
  Qt5::WebKitWidgets
  Qt5::PrintSupport
  Qt5::Concurrent

  KF5::Solid
  KF5::WindowSystem
  KF5::ConfigGui
  KF5::CoreAddons
  KF5::Service
  KF5::XmlGui
  KF5::I18n

  # Required by CImg which use pthread internally.

  ${CMAKE_THREAD_LIBS_INIT}

  ${LCMS2_LIBRARIES} # filters

  ${TIFF_LIBRARIES}
  ${PNG_LIBRARIES}
  ${EXIV2_LIBRARIES}

  libdng
  libraw
)


> the better version). It seems to me like the -lpng you see comes from
> QtWebkitWidgets, which would also need to be linked against your library

It does and is, but I don't find a reference to libpng in its cmake modules 
(nor 
in any other of Qt5's modules, for that matter).
So while your hypothesis seems reasonable I don't see where the -lpng would be 
added by Qt's modules. (FWIW, QtWebKit also has a .pc file, but it doesn't add -
lz after -lpng so unless someone reorders the link library order that file 
cannot 
be the source of the issue either.)

I've asked a more generic question about fully-qualified path conversion to 
-lfoo 
on the general ML ("/path/to/libpng.so automatic conversion to -lpng").

R.


-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

FWIW, I do question this rewriting feature, because it clearly can go wrong.

I'd argue that programmers (or build script/cmake modules/...) usually have 
good 
reason when they give the absolute path to a library: making darn sure it's 
indeed that one that gets linked.

While I agree that replacing a full path with the -lfoo notation makes the 
final 
command shorter and thus more readable it can also introduce subtle bugs. The 
fact that a library can be found by the linker because it's on the search path 
doesn't mean that the linker will find the right, intended library. In my case 
I 
could get the correct linking by just adding -L/opt/local/lib, but what if for 
some reason I had wanted to include the system libpng, i.e. if PNG_LIBRARIES 
had 
pointed to /usr/lib/libpng.so?

I hope this is not such a corner case that Kitware haven't foreseen it and 
implemented a way to deactivate the rewriting?

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Andreas Naumann wrote:

> cmake instrospects your compiler and asks for system directories. Only
> these system directories will be removed and the corresponding libraries
> will be linked by -l<...>. So, you should check your compiler and the
> environment. I had several problems years ago with the environment
> variable LIBRARY_PATH, which leads to such a behavior.

Hello Andreas,

Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I use).
>From what I understand, that variable allows you to specify a set of -L 
directories via an env. variable (other than LDFLAGS). 

It seems that clang handles that variable in a somewhat different manner than 
GCC does. Even in a very simple call on the commandline (including the -v 
option) I see it adds -L/opt/local/lib AFTER the user-supplied libraries, where 
GCC puts it before the 1st -l option.

R.


-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] /path/to/libpng.so automatic conversion to -lpng ?

[René J . V . Bertin]

Hi,

I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus 
*should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker 
command. Instead, I am getting a linker command line that has `-lpng -lz`, 
which fails for me because the `/path/to` in question isn't on the standard 
library search path.

Is there a cmake feature that does this automatic conversion, and if so how can 
I turn it off?

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

Volker Enderlein wrote:

Hi,

Thanks, that helps. With there is maybe something to learn from the CMake 
sources, too.

R.

> Hello,
> 
> according to https://sourceforge.net/p/predef/wiki/Compilers/ you could
> check with
> 
> check_cxx_source_compiles("
>  #if defined (_MSC_VER) && (_MSC_VER == 1900) && (_MSC_FULL_VER ==
> 190024210)
>  #else
>#error compiler is not MSVC Update3
>  #endif
>  int main() {
>  return 0;
>  }
> " MSVC_UPDATE3_FOUND)
> 
> for the requested feature.
> 
> HTH, Cheers, Volker
> 
> 
> Am 15/05/2017 um 14:56 schrieb René J.V. Bertin:
>> Hello,
>>
>> A question that will hopefully have a quick/easy answer:
>>
>> I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the
>> end) can be used instead of /Za . I know that a later update bumped the
>> version to 14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C
>> code so I could assume everyone keeps installs their updates and use that
>> value.
>>
>> But what does this translate to in CMake code (MSVC_VERSION)? Probably not
>> just 1903 I presume?
>>
>> Thanks,
>> René
> 


-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

René J.V. Bertin wrote:

Bump. No one who can help here?

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

On Monday May 15 2017 15:58:53 Konstantin Tokarev wrote:

Hello,

>Have you tried CHECK_CXX_COMPILER_FLAG?

I forgot to mention: I don't have a MS dev set-up at the moment. This is for a 
cross-platform purposes (in KDE's extra-cmake-modules).

Thanks,
R
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] How to detect MSVC 2015 update 3 (= presence of /fpermissive-)

[René J . V . Bertin]

Hello,

A question that will hopefully have a quick/easy answer:

I'd like to detect when the MSVC /fpermissive- (yes, that's a dash at the end) 
can be used instead of /Za . I know that a later update bumped the version to 
14.0.25422.01 and thus undoubtedly _MSC_FULL_VER== 1402542201 in C code so I 
could assume everyone keeps installs their updates and use that value.

But what does this translate to in CMake code (MSVC_VERSION)? Probably not just 
1903 I presume?

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 15:23:45 Robert Maynard wrote:

> Basically my recommendation is if a project isn't setting
> cmake_minimum_required before the first project call than nothing you
> can do will fix that, as it is an error.

The issue here is not that the minimum version was NOT being set. Apparently 
that isn't an issue if I set CMP0025 from the commandline. The issue was a 
project that requested an earlier CMake version (2.8.something) further down. 
Apparently that undoes the explicit CMP0025 setting, but not if I execute a 
cmake_minimum_required(3.0) first.

Either way, I'm getting signals from others using the build system this is 
about (MacPorts) to please not force a minimum required CMake version, and 
calling `cmake_minimum_required` in an initial cache file does not have the 
expected effect.

R.
-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Are you sure about the minimum required version? I cannot seem to have any luck 
with `-DCMAKE_MINIMUM_REQUIRED_VERSION=3.0`.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 03 2017 11:41:29 Robert Maynard wrote:

> It is the responsibility of the project to understand what components
> of CMake they require, and correctly specify a cmake_minimum required
> that satisfies all those requirements. In this case to use compile
> features you need a minimum of 3.0 which also automatically enables
> policy 25.

I agree with you in a way, but in reality it would be up to end users and 
packagers to feed back that information to an unknown number of projects and 
convince them why it's necessary to comply with the request. That's just not 
doable.
It would be a lot easier if the policy could be set at a central location, in 
this case in the Qt module invoking the test that fails.


And it's CMake's responsibility to generate useful error messages, and where 
possible provide a hint for the fix.

> You can explicitly do both of those things currently see:
> https://cmake.org/cmake/help/v3.0/manual/cmake-policies.7.html

Ah, thanks. I take it one can also change a line in cmPolicies.h:

  SELECT(POLICY, CMP0025, "Compiler id for Apple Clang is now AppleClang.",   \
 3, 0, 0, cmPolicies::NEW)   \

?

R.
-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

On Tuesday January 3 2017 10:02:44 Robert Maynard wrote:

Hi,

Thanks for the sample CMake file!

It appears indeed that the policy defaulting to OLD is the culprit here: 
setting it to NEW at an appropriate location (and throwing out 
build.dir/CMake*) makes detection work properly. Surprised me a bit TBH; a 
casual read (and unburdened with prior knowledge) of the CMP0025 doc seems to 
suggest that the opposite would happen.

That almost begs the question what you're waiting for to make the new setting 
the default. :)
Maybe there's a way to toggle it locally, so that it doesn't have to be set in 
every project that may need to be built with a non-Apple clang version?

Cheers,
René Bertin

>The problem that was reported in that other thread was due to having
>policy CMP0025 set to a false value, once that policy was enabled
>compiler detection worked properly.
>
>I would make sure the same isn't happening for you.
>
>I have attached a simple CMakeList.txt file you can use to determine
>if potentially you are seeing the same policy issue.
>
>
>
>On Tue, Jan 3, 2017 at 9:21 AM, René J.V. Bertin  wrote:
>> Hi,
>>
>> I just had a run-in with a CMake file from Qt5 in a project I've been 
>> building with a locally built Clang 3.9 version, affectionately called 
>> clang-mp-3.9 . I got the cryptic message
>>
>>  CMake Error in src/platformtheme/CMakeLists.txt:
>>No known features for CXX compiler
>>
>>"Clang"
>>
>>version 3.9.0.
>>
>>
>> Would you consider adding support for non-Apple clang versions on Mac too, 
>> and who would best request that, a Qt dev who considers the cxx_decltype 
>> test crucial, or the 1st user for whom that breaks his builds (i.e. me)?
>>
>> I see this has already come up for HB:
>> https://cmake.org/pipermail/cmake/2016-December/064719.html
>>
>>
>> Thanks,
>> René Bertin
>> --
>>
>> 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://public.kitware.com/mailman/listinfo/cmake-developers

-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[René J . V . Bertin]

Hi,

I just had a run-in with a CMake file from Qt5 in a project I've been building 
with a locally built Clang 3.9 version, affectionately called clang-mp-3.9 . I 
got the cryptic message

 CMake Error in src/platformtheme/CMakeLists.txt:
   No known features for CXX compiler

   "Clang"

   version 3.9.0.


Would you consider adding support for non-Apple clang versions on Mac too, and 
who would best request that, a Qt dev who considers the cxx_decltype test 
crucial, or the 1st user for whom that breaks his builds (i.e. me)?

I see this has already come up for HB:
https://cmake.org/pipermail/cmake/2016-December/064719.html


Thanks,
René Bertin
-- 

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://public.kitware.com/mailman/listinfo/cmake-developers

[CMake] check_include_file for Objective C(++) triggers what looks like a clang bug (but probably isn't)

[René J . V . Bertin]

Hi,

I've been trying to use the check_include_file() macro to verify if a 
particular ObjC header can be compiled. This turns out to be almost impossible, 
but I cannot put my finger on whether there isn't a compiler error involved too.

Let's take the easier case for Mac OS X, where you don't have to install 
GNUstep. The following statement could be expected to work:

check_include_file(Foundation/Foundation.h HAVE_FOUNDATION "-v -x objective-c")

but it fails. The -x argument is required, the -v option is purely for 
debugging. The error from CMakeError.log is copied below; it seems that the 
intermediate object file is corrupt. However, the same symptoms occur with a 
comparable test file built the same way with clang:

%> clang -x objective-c -c test.c
%> clang -x objective-c test.o

However, 

%> clang test.o
and
%> clang -x objective-c test.c

work fine, and it's clear from the trace output that the -x option should NOT 
be passed to clang when it's used as a linker driver.

Questions:
- is there a more appropriate way to check if an Objective C header can be 
compiled?
- is there a way to configure or set up things such that the trycompile 
functions use a single compiler invocation, or test only the object file 
generation (which should be enough for testing a headerfile)?

Thank,

René
CMakeError.log extract:

Building C object CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-O3 -march=native -g -v -x objective-c 
-isystem /usr/include/GNUstep-o 
CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o   -c ...//src/MSWin/
SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/CheckIncludeFile.c
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
 
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
 -cc1 -triple x86_64-apple-macosx10.9
.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name 
CheckIncludeFile.c -mrelocation-model pic -pic-level 2 -mdisable-f
p-elim -masm-verbose -munwind-tables -target-cpu corei7-avx 
-target-linker-version 241.9 -v -gdwarf-2 -coverage-file 
...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o
 -resource-di
r 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0
 -isystem /usr/include/GNUs
tep -I/opt/local/include -O3 -fdebug-compilation-dir 
...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/
CMakeTmp -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign 
-fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extend
ed-block-signature -fobjc-exceptions -fexceptions -fdiagnostics-show-option 
-vectorize-loops -vectorize-slp -o CMakeFiles/cmTC_61f5f
.dir/CheckIncludeFile.c.o -x objective-c 
...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp/Che
ckIncludeFile.c
clang -cc1 version 6.0 based upon LLVM 3.5svn default target 
x86_64-apple-darwin13.4.0
ignoring nonexistent directory "/usr/include/GNUstep"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/include
 /usr/local/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
Linking C executable cmTC_61f5f
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTC_61f5f.dir/link.txt 
--verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
  -O3 -march=native -g -v -x objective-c -isystem /usr/include/GNUstep  
-Wl,-search_paths_first -Wl,-headerpad_max_install_names   
CMakeFiles/cmTC_61f5f.dir/CheckIncludeFile.c.o  -o cmTC_61f5f  
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
 
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
 -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free 
-disable-llvm-verifier -main-file-name CheckIncludeFile.c.o -mrelocation-model 
pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu 
corei7-avx -target-linker-version 241.9 -v -gdwarf-2 -resource-dir 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0
 -isystem /usr/include/GNUstep -I/opt/local/include -O3 -fdebug-compilation-dir 
...//src/MSWin/SynchroTr/CMake/Release/CMakeFiles/CMakeTmp -ferror-limit 19 
-fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks 
-fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature 
-fobjc-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops 
-vectorize-slp -o 

[CMake] OS X Info.plist with POSIX executables and libraries (no app/framework bundles)

[René J . V . Bertin]

Hi,

I'd like to do something like

set_target_properties(foo PROPERTIES MACOSX_BUNDLE_INFO_PLIST 
${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in)
set_target_properties(foo PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER "org.bar.foo")
# etc

for an application that will not be an app bundle but a regular POSIX 
executable. The resulting Info.plist can easily be included in the executable by

target_link_libraries(foo "-sectcreate __TEXT __info_plist 
${CMAKE_CURRENT_BINARY_DIR}/Info.plist")

but the template Info.plist isn't processed at all.

What's the best way to replace the above standard sequence of Info.plist set-up 
commands to obtain a preprocessed Info.plist that has the correct values 
substituted for the variables in the template?

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Nicholas Braden wrote:

> Ah, I understand now - I have a habit of forgetting that you can
> configure existing CMake builds by repeatedly invoking cmake. I don't
> know if such a feature exists but it definitely sounds useful.

Yes, that would be another use case!

R.


-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Nicholas Braden wrote:


> sense. Could you give an example of when you would find them useful? I
> think maybe I am not understanding what you want.

Yeah, I realise my explanation may not have been very clear.

> If you just want to pass a list of values to a variable on the command
> line, separate the values with semicolons:
> cmake "-DMY_LIST=example value 1;example value 2"


Now take an example where you are in fact assembling the commandline in 
subsequent steps. A good example would be a build system like MacPorts that 
uses 
a kind of header files (so-called PortGroups) that can be included by the build 
scripts for packages of dependent software (say, the Kate5 editor). There's a 
PortGroup for cmake itself, and there's a PortGroup for Qt5 and one for the KF5 
frameworks. Each of those PortGroups can provide an element for MY_LIST (think 
of the module path, or preprocessor tokens), but evidently they cannot make 
assumptions about the contents of the variable.

In other words, it would make sense for certain types of programmatically 
generated commandlines to do things like

cmake -DMY_LIST+=val1 -DMY_LIST+=val3 -DMY_LIST+=val2 

At the moment we can do this reliably by using our own registers, one for each 
CMake variable that might be used this way, splicing them into the commandline 
just before invoking cmake. Not impossible, but somewhat of a hassle and a pity 
for a feature that seems useful and probablye rather trivial to implement.

CMake commandline can get quite long, so this might even make sense as a 
convenience for composing one manually.

Of course it would be convenient to have a concatenation operator in the cmake 
language too ;)

R


-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] why no cumulative variable operations via the commandline?

[René J . V . Bertin]

Hi,

I've been wondering about something that is a real stumbling block in a 
build/distribution system like MacPorts where settings can be modified in any 
number of consecutive steps. For instance, depending on what dependencies a 
package ("port") requires and how those dependencies are installed, elements 
may 
be added to the module search path repeatedly.

In cmake language one does cumulative operations like that explicitly, but I'm 
not aware of any way to do that on the command line.

Is there a reason why one cannot do something like 

cmake -DCMAKE_FOO+=bar

or

CMAKE -ACMAKE_FOO=bar (-A for add instead of define)

(or -DCMAKE_FOO-=bar, for that matter...) ?

Thanks,
René

-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] [OS X] example CMake file to create a Preference Pane?

[René J . V . Bertin]

Hi,

I'd like to experiment writing a Preference Pane for Qt-based apps. I'd prefer 
to use CMake instead of Xcode and wonder if someone can point me to an example 
CMake file that generates a proper .prefPane bundle? I'm not having much luck 
googling for one for now.

Thanks,
René

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Make CMAKE_EXPORT_COMPILE_COMMANDS not default?

[René J . V . Bertin]

Hello,

Sorry for reviving an old thread 
(https://cmake.org/pipermail/cmake/2013-December/056517.html) but it seems to 
have died without a proper answer, at least one that I could find.

I'd like to offer an additional reason why CMAKE_EXPORT_COMPILE_COMMANDS would 
be beneficial if on by default, one that apparently didn't come up.
IDEs like KDevelop and QtCreator use this option to know the layout/contents of 
a project. They will add it to the cmake invocation when you create a new build 
directory for said project. However, they can also be pointed to an already 
existing build directory, in which case it'd be preferable if they didn't have 
to run cmake again (neither IDE has the option to run cmake under the kind of 
strictly controlled environment that might be required to configure it "just 
right").

Regards,
René

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

[René J . V . Bertin]

Dan Liew wrote:

> Hi,
> 
> 
>> - If not, what is the best/official way to get exact control over the
>> compiler and linker options used?
> 
> I had to do something similar recently where I didn't want
> ``-DNDEBUG`` to be in any of the configurations.
> 
> I used  ``CMAKE_USER_MAKE_RULES_OVERRIDE `` to set the path to file
> containing overrides, this must be set before calling ``project()``

> I'm not sure if this is really the correct route to go down though for
> your use case.

That wouldn't be impossible. A more generic way to achieve what you did, one 
that doesn't require patching "client" CMake files (which I find unacceptable):

Store the customised settings in a file (I'd call it cmake.initcache) and call 
cmake as

%> cmake -C./cmake.initcache "$@"

This is an approach I follow with a more basic building workflow of my own, one 
where I keep localised/customised settings (CC/CXX, CFLAGS/CXXFLAGS, LDFLAGS 
etc) in a ./wconfigure.env file, which is parsed by wrappers to configure and 
cmake. It's not a usual approach for MacPorts, though.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

[René J . V . Bertin]

René J. V. Bertin wrote:

Similarly, is there a way to set preprocessor variables (cf. 
https://cmake.org/Bug/view.php?id=12928 which has been silent for a long time)?

One could do -DINCLUDE_DIRECTORIES=${CPPFLAGS}, but that may lead to unexpected 
results if CPPFLAGS contains something other than -I options.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] CMAKE_BUILD_TYPE and exact control of compiler options

[René J . V . Bertin]

Hello,

I'm using cmake in conjunction with a packaging/distribution system that aims 
to 
control the compiler and linker flags, a priori via the usual environment 
variables. (We're talking about MacPorts.)

Using one of the CMAKE_BUILD_TYPE presets, the value of those env. variables 
appears at most to be added in front of the preset options, which means user 
options can be overridden. That may be intended behaviour, but not ideal for my 
use case.

Working with Debian and Ubuntu systems, I deduced that using a non-pre-defined 
BUILD_TYPE make cmake use the values of CFLAGS, CXXFLAGS etc, through 
CMAKE_C_FLAGS, CMAKE_CXX_FLAGS etc (instead of CMAKE_C*_FLAGS_RELEASE, for 
instance).

Experimenting with -DCMAKE_BUILD_TYPE=MacPorts in the toplevel control file 
(cmake PortGroup), that appeared indeed to work, but I appear to have been 
mistaken. Adding -DCMAKE_C*_FLAGS_MACPORTS definitions has no effect, nor has 
setting CMAKE_C*_FLAGS from the CMake command line.

Which leads me to the following questions:
- Is it indeed possible to get CMake to take all compiler and linker flags from 
the environment, and if so, how?
- If not, what is the best/official way to get exact control over the compiler 
and linker options used?
- Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build 
type? 

Thanks
René Bertin

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMAKE_BUILD_TYPE and exact control of compiler options

[René J . V . Bertin]

Andreas Pakulat wrote:


> No this is not possible in general. A CMakeLists.txt file can always just
> set their own compiler/linker flags.

Which would require patching each and every one of them, which isn't exactly 
desirable.

>> - Out of curiosity, what's special about the CMAKE_BUILD_TYPE=Debian build
>> type?
>>
> 
> There's no such build type in CMake, see the Compilers and Tools section
> here: https://cmake.org/Wiki/CMake_Useful_Variables#Various_Options that
> details the built-in types in CMake.

I know it doesn't exist as a preset in CMake. But take a look at the CMake 
files 
shipped with KDE4's kdelibs: those actually introduce CMAKE_C*_FLAGS_DEBIAN 
variables (in addition to using specific install locations, for instance).
It's quite important that there is such a feature: configure and its 
alternatives 
are supposed to take CFLAGS, CXXFLAGS and family into consideration (or at 
least 
should have a mode in which they do, IMVHO).

I suppose that what happens is that requesting an unknown CMAKE_BUILD_TYPE is 
equivalent to not requesting one at all, and also prevents downstream CMake 
files 
to pick a default preset if CMAKE_BUILD_TYPE hasn't been defined by the caller.
I've had a better look at the control file I mentioned, and found the reason 
why 
$CFLAGS and $CXXFLAGS weren't being used. 

It turns out that if you set CMAKE_CXX_FLAGS on the commandline, it is no 
longer 
set to include $CXXFLAGS from the environment. Comments in the control file 
suggest that that wasn't always the case.

R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] --prefix commandline option?

[René J . V . Bertin]

Hello,

I discovered by accident that cmake (3.2.2) apparently respects the --prefix 
command line option, with a result that's somewhat different from setting 
CMAKE_INSTALL_PREFIX. I cannot seem to find any documentation on this feature 
though: have I overlooked it, or is this indeed an undocumented feature that 
shouldn't be used? If that latter option, is there a -DCMAKE_??? equivalent 
that has the same effects?

Thanks,
René


-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] --sphinx-qthelp leads to build error with CMake 3.2.3

[René J . V . Bertin]

Hi,

I'm trying to build the latest CMake release, with the Qt4 gui and including 
the docs in Qt help format. I'm using the same recipe as for the 3.2.2 
release, but now I see this:


[ 95%] sphinx-build qthelp: see Utilities/Sphinx/build-qthelp.log
cd /build//cmake-3.2.3/Utilities/Sphinx  /opt/local/bin/sphinx-build-3.4 -c 
/build//cmake-3.2.3/Utilities/Sphinx -d 
/build//cmake-3.2.3/Utilities/Sphinx/doctrees -b qthelp 
/build//cmake-3.2.3/Help /build//cmake-3.2.3/Utilities/Sphinx/qthelp  
build-qthelp.log
WARNING: 'default' html theme has been renamed to 'classic'. Please change your 
html_theme setting either to the new 'alabaster' default theme, or to 'classic' 
to keep using the old default.
cd /build//cmake-3.2.3/Utilities/Sphinx  ../../Bootstrap.cmk/cmake 
-DCSS_DIR=/build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static -P 
/build//cmake-3.2.3/Utilities/Sphinx/apply_qthelp_css_workaround.cmake
CMake Error at apply_qthelp_css_workaround.cmake:4 (file):
  file failed to open for reading (No such file or directory):

/build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static/default.css


Utilities/Sphinx/CMakeFiles/documentation.dir/build.make:63: recipe for target 
'Utilities/Sphinx/doc_format_qthelp' failed
make[2]: *** [Utilities/Sphinx/doc_format_qthelp] Error 1


I cannot vouch that the WARNING wasn't already there last time, but the fact 
that a file called default.css is missing while there is a classic.css might be 
significant.

I've google the error a bit, but so far haven't found anything relevant AND 
recent.

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] determining which system headerfile provides a given function

[René J . V . Bertin]

On Monday June 15 2015 23:05:07 Alexander Neundorf wrote:

 if you have multiple candidate headers, try them all, and use separate result 
 variables for every one.
 Is that the problem you have ?

Yes. That's probably the thing I missed and why it didn't work; I used a single 
variable.
Still, it seems surprising there's no predefined macro that would help make 
things easier in this kind of scenario that cannot be that uncommon (at least 
it used to be quite common, like for instance with string.h vs. strings.h).
A macro that takes a list of candidates and returns the name of the appropriate 
file would seem useful, no?

R.
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] wrapping a macro

[René J . V . Bertin]

Hello,

Is it possible to wrap an existing macro that returns a result via one of its 
arguments? I think it will be clear what I would like to do from the following 
example:

if(${INTRINSICS_TEST_TYPE} MATCHES compiles)
macro(check_intrinsics_availability source var)
check_c_source_compiles(source var)
endmacro()
elseif(${INTRINSICS_TEST_TYPE} MATCHES runs)
include(CheckCSourceRuns)
macro(check_intrinsics_availability source var)
check_c_source_runs(source var)
endmacro()
elseif(${INTRINSICS_TEST_TYPE} MATCHES none)
macro(check_intrinsics_availability source var)
set(${var} 1)
set(${var}_EXITCODE 0)
endmacro()
else()
macro(check_intrinsics_availability source var)
set(${var} 0)
set(${var}_EXITCODE 1)
endmacro()
endif()


This does not have the intended effect: when INTRINSICS_TEST_TYPE == 
compiles, 
cmake prints Performing test var - Failed. Evidently I'd like it to perform 
test ${var}, in other words, the check_intrinsics_availability macro should 
behave exactly as either check_c_source_compiles or check_c_source_runs.

Additionally, the none and fallback cases are supposed to behave if 
check_c_source_?? succeeded or failed, respectively. Are they implemented 
correctly?

Thanks,
R.

-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] determining which system headerfile provides a given function

[René J . V . Bertin]

On Saturday June 13 2015 22:26:12 Alexander Neundorf wrote:

 did you try check_symbol_exists() and the other similar functions ?

Yes, but none that I could find give any information beyond whether the symbol 
exists. It may be possible (or necessary) to repeat such tests trying each of 
the possible candidate header files in succession until a hit is found, but as 
I said in my initial email, that doesn't work. That's about all there's to say 
about it: I presume this approach doesn't work because of caching intended to 
avoid testing the same thing twice.

René
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] determining which system headerfile provides a given function

[René J . V . Bertin]

Hello,

I need to determine the availability of a certain function (reallocf) and which 
headerfile provides its prototype.
If there is a function that handles this case I must have overlooked it 
(including on google), so I tried repeating a check_symbol_exist() call 
repeatedly with the various known header file paths. But that also doesn't 
work, either because of caching or because I'm doing something else wrong.

So, how does one handle this kind of situation?

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] determining which system headerfile provides a given function

[René J . V . Bertin]

Ok, let me rephrase the question to see what other kind of constructive answers 
that'll lead to:

how does one check which header file provides the prototype for a function from 
the system libraries?
Function in question: reallocf; can apparently be in either stdlib.h or 
bsd/stdlib.h .

-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] linking a C application with a C++ library

[René J . V . Bertin]

Hello,

I'm trying to write a cmake file for an older project of mine, which consists 
of a library (mostly C++) and a few test cases one of which is a C programme to 
test the library's functionality exported to C. I'd like to use a single cmake 
file, but am getting link error on the C app, most likely because it should be 
linked by the C++ linker (or at least with -X c++).

How do I instruct cmake to do this?

Thanks,
R.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] linking a C application with a C++ library

[René J . V . Bertin]

On Wednesday June 03 2015 02:44:29 René J.V. Bertin wrote:

 How do I instruct cmake to do this?

never mind:

set_target_properties(cseTest PROPERTIES LINKER_LANGUAGE CXX)

Sorry for the noise!

R.
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] repetitive path gives filename too long errors

[René J . V . Bertin]

Hello,

I'm struggling with the py-pykde4 package, which is giving me filename 
overflows due to constructing a path that contains repetitions of itself. I 
first ran into this in November, have since updated to CMake 3.1.2, and now see 
that the issue hasn't been solved:

https://mail.kde.org/pipermail/kde-mac/2014-November/002404.html

and that I'm not the only one:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750231

I saw a hint that using Ninja might avoid the issue, and indeed the cmake step 
works fine with that generator. However:

% (cd py27-pykde4-mp9-work/build/ ; ninja)
/Volumes/Debian/MP9/var/macports/build/_Volumes_Debian_MP9_site-ports_python_py-pykde4/py27-pykde4/work/build
ninja: error: 
stat(_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc):
 File name too long
ninja: error: 
stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util):
 File name too long
ninja: error: 
stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util):
 File name too long
ninja: error: 
stat(CMakeFiles/_Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build__Volumes_Debian_MP9_var_macports_build__Volumes_Debian_MP9_site-ports_python_py-pykde4_py27-pykde4_work_build_pykdeconfig.pyc.util):
 File name too long
(etc)

Is this because of an error in pykde4's CMake files, or is this an unavoidable 
side-effect of the way CMake works?
NB: I tried setting pykde4_SOURCE_DIR and pykde4_BINARY_DIR on the commandline, 
but that had no effect (other than that the values appeared in CMakeCache.txt).

Thanks,
René
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] control python exec. search from command line?

[René J . V . Bertin]

Hello,

I'm trying to build a project that uses FindPythonInterp.cmake to locate the 
python executable. Thing is that the system I'm working on has python 
pointing to a 2.7 install, while the project requires Python 3.x. Is there a 
way to influence the search from the command line? I tried

-DPYTHON_EXECUTABLE:PATH=/path/to/python3

but that didn't cut it.

Am I going to have to patch the CMake file that invokes the FindPythonInterp 
routine instead?

Thanks,
R.
-- 

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] control python exec. search from command line?

[René J . V . Bertin]

On Friday February 27 2015 10:44:11 Omar Valerio wrote:
Hello Omar,

Well yes I suggest you to use a FIND_LIBRARY directive inside your
CMakeList.txt project file and HINT the compiler which location to prefer
for the library to get linked.  (
http://www.cmake.org/cmake/help/v3.0/command/find_library.html)

Except that there's no need for a library, but for the python interpreter. The 
project in question is kdev-python (1.6.1) .

Would be helpful to know which version of CMake are you running, because in
previous versions of CMake there was a bug preventing CMake to found the
correct Python libraries. You can read more about here:

3.1.2

Other than that there is and specific FindPython3Libs cmake module that you
may want to try.  Here is the location where you can find it:

https://qt.gitorious.org/pyside/shiboken/source/fdf8e4b70e2a82cda581ceae06a1c98fb20114f0:cmake/Modules/FindPython3Libs.cmake

Thanks, I'll have a look ... but I'd just as much NOT introduce another 
dependency ...

I'll ask around on the kdevelop ML too.

R
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] How to find Python 2.7 libraries if 3.x is installed too

[René J . V . Bertin]

Hello,

I am trying to get a not-so-old project to build (gizmod.sourceforge.net) which 
requires Python2.7 and libboost-python. 
I cannot seem to figure out how to do a find_package(PythonLibs REQUIRED) that 
will not consider that Python 3.4 is a suitable newer version of Python 2.7 . 
Is that even possible? The documentation in FindPythonLibs.cmake suggests that 
one can limit the search to specific versions, but that doesn't work.
And using find_package(PythonLibs 2.7.5 EXACT REQUIRED) raises an error because 
it too finds v3.4 ...

Thanks,
R.B.
-- 

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://public.kitware.com/mailman/listinfo/cmake

[CMake] how to define global compiler flags that are inserted before user-defined flags?

[René J . V . Bertin]

I was referred here from http://public.kitware.com/Bug/view.php?id=15127 ... so 
here goes:

KDE defines a number of compiler options that are (supposedly) required but 
that include optimisation options. These settings are defined in system-wide 
.cmake files like FindKDE4Internal.cmake and get applied *after* user-specified 
settings have been applied. They even seem to override tweaks made directly in 
CMakeCache.txt (to CMAKE_CXX_FLAGS_RELEASE or _RELWITHDEBINFO).
Even if user-specified compiler flags do make it to the list in the generated 
*.make files, the KDE/system-defined options are *appended* to the list, 
causing -O2 to override -O3 or -g -g3. 

Is it possible to specify the KDE/system options in such a way that they appear 
at the start of the options list in the *.make files?
With user-defined I mean specified on the commandline, through the environment, 
or (even) by editing CMakeCache.txt .
I raised an issue about this on bugs.kde.org, but it could be constructive to 
be able to propose a solution/alternative (and I guess the real experts are 
here, not on kde.org ;) ).

Regards,
René Bertin
-- 

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://public.kitware.com/mailman/listinfo/cmake