[cmake-developers] [CMake 0014272]: CodeBlocks generator does not include generated files
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14272 == Reported By:rikky Assigned To: == Project:CMake Issue ID: 14272 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-04 16:37 EDT Last Modified: 2013-07-04 16:37 EDT == Summary:CodeBlocks generator does not include generated files Description: Generated files are not included in the project tree. I think this was accidently introduced with 2a9f7f96b804ed929c56826c8477895c5924befe (Also add the SOURCES from add_custom_target() to CodeBlocks projects (http://public.kitware.com/Bug/view.php?id=11736)). This patch added SOURCES from add_custom_target, but removed generated files for other targets (i.e. add_library). I attached a possible fix, but I'm not sure I use the right coding style. == Issue History Date ModifiedUsername FieldChange == 2013-07-04 16:37 rikky New Issue 2013-07-04 16:37 rikky File Added: add_generated_files.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using multiple toolchains
I just want to express that we (ReactOS) are also a victim of this separation between native and cross compiling CMake invocations, because we depend on some host tools that we must compile natively, in order to use them later on when compiling ReactOS itself. In Windows for example, the native and the cross compiling toolchains can be (and they often are) one and the same, so having this separation is.. interesting. We also use Visual Studio but the CMake generated solution is far from a normal/expected VS solution, because it doesn't make use of VS' support of multiple toolchains in one solution, and the support of host/target toolchains. What you get is two solutions where you must open the host tools (native) one first, compile it, then close it and open the target one (cross compiling) in order to really start compiling anything (the native solution exports the not tools). Being the one who converted ReactOS from rbuild (our own build system) to CMake, when I discovered this problem, I was hoping that it's simply due to my lack of understanding and familiarity with CMake (I knew *nothing* about CMake when I started the experiment in a ReactOS branch), but until today, we're still having two build folders: one for host tools and one for the actual ReactOS. Inspecting the ExternalProject approach not only led to even more complex build scripts and no success in implementing one CMake invocation to get things done (we tried), but also led to going even farther from the expected VS behavior when it comes to multiple toolchains. As you can see, we really feel the pain and the need for a proper, CMake based, VS aware approach to multiple toolchains, and I wanted you to know that we really welcome such a long overdue effort ! Cheers, Amine. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014271]: find_package PythonInterp and PythonLibs are not consistent
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14271
==
Reported By:Hans Johnson
Assigned To:
==
Project:CMake
Issue ID: 14271
Category: (No Category)
Reproducibility:always
Severity: major
Priority: high
Status: new
==
Date Submitted: 2013-07-04 11:15 EDT
Last Modified: 2013-07-04 11:15 EDT
==
Summary:find_package PythonInterp and PythonLibs are not
consistent
Description:
On mac when specifying the requested python version, the wrong paths are being
specified inconsistently.
When a specific version is requested, the paths should be taken from:
/System/Library/Frameworks/Python.framework/Versions/2.X/
Steps to Reproduce:
On mac configure this package:
cmake_minimum_required(VERSION 2.8.11)
foreach(REQUIRED_PYTHON_VERSION 2.7 2.6 2.5 )
message(STATUS " LOOKING FOR ${REQUIRED_PYTHON_VERSION}
")
find_package ( PythonInterp ${REQUIRED_PYTHON_VERSION} REQUIRED)
find_package ( PythonLibs ${PYTHON_VERSION_STRING} EXACT)
#find_package ( PythonLibs ${PYTHON_VERSION_STRING} EXACT REQUIRED )
message(STATUS "PYTHON_EXECUTABLE:FILEPATH=${PYTHON_EXECUTABLE}")
message(STATUS "PYTHON_LIBRARY:FILEPATH=${PYTHON_LIBRARY}")
message(STATUS "PYTHON_INCLUDE_DIR:FILEPATH=${PYTHON_INCLUDE_DIR}")
unset(PYTHON_EXECUTABLE CACHE)
unset(PYTHON_LIBRARY CACHE)
unset(PYTHON_INCLUDE_DIR CACHE)
endforeach()
Additional Information:
johnsonhj@neuron$ ls -al /System/Library/Frameworks/Python.framework/Headers
lrwxr-xr-x 1 root wheel 24 May 21 08:33
/System/Library/Frameworks/Python.framework/Headers@ -> Versions/Current/Headers
/scratch/johnsonhj/src/Testing
johnsonhj@neuron$ ls -alrth
/System/Library/Frameworks/Python.framework/Versions/Current
lrwxr-xr-x 1 root wheel 3B May 20 14:00
/System/Library/Frameworks/Python.framework/Versions/Current@ -> 2.7
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-04 11:15 Hans Johnson New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using multiple toolchains
Brad King wrote: > On 7/1/2013 1:26 PM, Stephen Kelly wrote: >> I've pushed a proof-of-concept multiple-toolchains branch to my clone >> which enables the use of multiple toolchains with cmake. > > Wow, that is a mind-blowing branch ;) That's a good reaction :). >> The idea is to use a separate cache and set of definition overrides for >> each toolchain. > > That sounds a lot like a separate invocation of CMake for each > toolchain, which is what one must do now. It's not very similar. * There is less for the buildsystem maintainer or invoker of the cmake executable to do. * The cmake-targets for the host and the target are 'closer together'. There doesn't need to be a separate buildsystem of host tools. >> One of the goals I have is to make it possible to use N different >> toolchains, not just two. > > Currently we support only one toolchain per language per build tree, > not even two. When one needs host tools we require two separate > builds. Correct. Or ExternalProject as you say below. >> There's obviously a clash of output binary names, cmake target names and >> make target names if the same library is going to be build for multiple >> toolchains. That's something I have not yet attempted to solve. > > These among many other challenges await anyone that attempts your > proposed approach. ... but only if the goal is N toolchains. My approach comprises several steps: 1. Refactor cmake so that more that one toolchain can be available at a time. 2. Make host+target builds possible in a single buildsystem by initializing both the host and the target toolchain, specifying whether to find dependencies in the host or the target, and specifying whether to build a particular cmake-target for the host or for the target system. This does not expose us to problems of clashes of cmake-target names for multiple toolchains or problems of defining multiple per-toolchain make-targets for a single cmake-target as all of those things remain impossible at this step. This step requires some way to define such distinctions in front-end CMakeLists.txt files. Possibly something like a toolchains() command scoped to end with a endtoolchains() command. 3. Make it possible to define multiple toolchains to build a single target for. Still only two toolchains are possible (host+target), but now we can define that a single cmake-target created with add_executable should be built for both the host and the target. Consider moc for example, which might make sense to build for both so that target-on-target builds (or target-in-target-vm builds) can be done. In addition to step two, this step requires solving the disabmiguation problems of cmake-targets and other problems that come from using multiple toolchains from one cmake-target definition. 4. Make it possible to use N target toolchains. This takes advantage of the solutions created in step 3. In addition to step 3, this step requires deprecation of the undocumented CMAKE_TOOLCHAIN_FILE in favor of something which can be a list, and it requires some way of attaching names to toolchains. Projects using this have the disadvantage that there is nothing but convention to standardise toolchain names. One project might use RaspPi as a toolchain name in a CMakeLists.txt file, while another uses RaspberryPi and yet another Raspbian. Qt has a similar issue with device mkspec names. > While the work in your branch has gotten > impressively far, it also serves to demonstrate the inherent > complexity of the proposed approach. IMO it is not worth exploring > that approach further. Sorry. That reaction is not what I was hoping for. :) My branch makes a start mostly on steps 1 and 2 above, and to a small extent, step 4. 80% of the motivation and value of multiple toolchains comes from step 2, so I would happily truncate the other two as goals or leave them to future exporation. I don't think an inappropriate amount of work or fundamental change to cmake is required to achieve step 2. > Much of the multiple toolchains functionality can be accomplished by > using ExternalProject to create a "superbuild" in which each inner > project uses a different toolchain file. From that one can get to > a single make invocation to drive everything. It doesn't need any > fundamental changes in CMake. I haven't used ExternalProject before today, though I was already aware of the existence of it, having read various discussions about it on the mailing lists. I added an example to my branch which uses it in an equivalent way with a simple host+target buildsystem. Apart from learning how to use it, which I documented with commits, I have the following notes: * The host compilations can be run in parallel, and the target compilations can be run in parallel, but the host compilations can't be done in parallel with the target compilations. A larger project than my exampl
Re: [cmake-developers] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT
Brad King wrote: > Oops, I should have noticed that while reviewing the CMAKE_SYSROOT topic. > This will need to be a per-language flag. Please replace that with > something like > > CMAKE__COMPILE_OPTIONS_SYSROOT > Done. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Alexander Neundorf wrote:
>> For the Qt configure, the answer is the latter, and I think it makes
>> sense. As CMAKE_SYSROOT is new, we can still change the behavior to that.
>> I tend to think we should.
>
> Not quite sure.
> I tend to agree.
>
> Different question: is CMAKE_FIND_ROOT_PATH actually still necessary ?
> With a combination of CMAKE_SYSROOT and CMAKE_PREFIX_PATH most cases
> should be handled already.
I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH which
can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on the
command line, I think). Should we enumerate the use cases to consider
documenting it obsolete?
> Then there would be two different install prefixes. Which would be used
> when ?
In the case of installing KArchive for example:
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make
I didn't specify the CMAKE_INSTALL_PREFIX, so it defaults to /usr/local in
the sysroot, ie /opt/rpi/rasp-pi-rootfs/usr/local.
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make \
-DCMAKE_INSTALL_PREFIX=/opt/kf5
would cause installation to /opt/rpi/rasp-pi-rootfs/opt/kf5. However, in
either case, I might want to keep a pristine sysroot, as argued in the Qt
review request I linked previously, which allows me to have multiple
KArchive builds without polluting the sysroot.
cmake .. -DCMAKE_TOOLCHAIN_FILE=../ArmToolchain.cmake \
-DCMAKE_SYSROOT=/opt/rpi/rasp-pi-rootfs/ \
-DCMAKE_MAKE_PROGRAM=/usr/bin/make \
-DCMAKE_INSTALL_PREFIX=/opt/kf5 \
-DCMAKE_HOST_INSTALL_PREFIX=$HOME/dev/cross-no-lzma/kf5
or
...
-DCMAKE_HOST_INSTALL_PREFIX=$HOME/dev/cross-with-lzma/kf5
This is similar to what Brad wrote:
> If a project wants to install inside the sysroot it can set
> CMAKE_INSTALL_PREFIX to point there. The user may want to
> install in $HOME/somewhere while the toolchain sysroot is
> a root-owned directory that cannot be modified by the user.
So, my suggestion is
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=/opt/kf5
and Brads suggestion is to stay with the currently required
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=/opt/rpi/rasp-pi-sysroot/opt/kf5
(assuming a rw sysroot)
However, if the CMAKE_INSTALL_PREFIX is used as a hardcoded and absolute
path-on-the-target for any reason (eg in unit tests), there would have to be
string manipulation to remove the CMAKE_SYSROOT in the host!=target case in
the CMakeLists.txt file.
If the install prefix is outside the sysroot, it just becomes impossible to
get a path-on-the-target for the install prefix with the current code,
unless it's specified additionally in a project-specific variable:
cmake .. -DCMAKE_SYSROOT=/opt/rpi/rasp-pi-sysroot \
-DCMAKE_INSTALL_PREFIX=$HOME/dev/kf5 \
-DKF5_TARGET_RUNTIME_PREFIX=/opt/kf5
> We already have
>
> $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/${install_dest}
Goals:
* Install to /opt/kf5 on the target
* Install to $HOME/dev/kf5 on the host
What values should be used for CMAKE_INSTALL_PREFIX and DESTDIR?
> How do install() invocations distinguish which prefix to use?
I think install invokations use CMAKE_HOST_INSTALL_PREFIX for everything if
present, and CMAKE_INSTALL_PREFIX otherwise.
> Does this tie into your multi-toolchain work?
If that goes ahead in some form, CMAKE_HOST_INSTALL_PREFIX would be where
install() would put anything bound for the target (the name now starts to
get confusing), and CMAKE_HOSTTOOLS_INSTALL_PREFIX (to simply pick another
name - yes the names are not good enough) for anything bound to the host.
This is completely orthogonal to the multi-toolchain work, except for the
sake of avoiding name clashes.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014270]: FindPythonInterp does not find IronPython
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14270 == Reported By:lost Assigned To: == Project:CMake Issue ID: 14270 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-07-04 03:40 EDT Last Modified: 2013-07-04 03:40 EDT == Summary:FindPythonInterp does not find IronPython Description: FindPythonInterp does not look for IronPython Steps to Reproduce: 1. Install IronPython 2.7.3, and no other pythons 2. Call FindPythonInterp Expected: ipy 2.7.3 should be found Actual: it is not Additional Information: I've attached FindPythonInterp, which has my dumb fix for this issue (added ipy as valid python name + looking in IronPython specific registry key) == Issue History Date ModifiedUsername FieldChange == 2013-07-04 03:40 lost New Issue 2013-07-04 03:40 lost File Added: FindPythonInterp.cmake == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
