[CMake] documentation on how to use cmake as an "end-user"?
Hi all, As a developer using CMake, I'd like to add to the README a link to general documentation on how to use CMake to build the source code. Something like this, but it's a bit out of date: https://cmake.org/runningcmake/ Is there something more recent I can link to? I've looked into the documentation, and while I very much appreciate it as reference on how to write CMakeList.txt, I didn't find anything suitable. Thanks, Bram -- 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] FindPython.cmake in older CMake version
Hi,
I'm testing out CMake 3.12, and I very much like the new
FindPython.cmake. Being able to use targets for the Python libraries
means I can much easier package my own library without hardcoded paths.
The only thing is that I want to be compatible with older CMakes >=
3.0. Therefore I came up with following approach: write a
FindPythonCompat.cmake that forwards to FindPython.cmake if CMake >=
3.12, and uses FindPythonInterp.cmake and FindPythonLibs.cmake to mimic
the new FindPython.cmake if CMake < 3.12.
You can find that file attached.
Instead of calling this:
find_package(Python 2.7 EXACT REQUIRED COMPONENTS Interpreter
OPTIONAL_COMPONENTS Development)
I now do this:
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}/cmake) #
contains FindPythonInterp.cmake
find_package(PythonCompat 2.7 EXACT REQUIRED COMPONENTS Interpreter
OPTIONAL_COMPONENTS Development)
The resulting targets and variables are the same as the ones from
FindPython.cmake.
Another approached I consider is a bit more cunning: add a
PythonConfig.cmake and PythonConfigVersion.cmake to CMAKE_PREFIX_PATH.
PythonConfig.cmake would not contain the forward to FindPython.cmake,
but it would instead rely on the fallback from MODULE to CONFIG mode
when FindPython.cmake cannot be found in CMake < 3.12. I would then
still be calling find_package(Python) but I extend CMAKE_PREFIX_PATH:
list(APPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_LIST_DIR}/cmake) #
contains PythonConfig.cmake
find_package(Python 2.7 EXACT REQUIRED COMPONENTS Interpreter
OPTIONAL_COMPONENTS Development)
In both cases it is of course required that I install this
FindPythonCompat.cmake or PythonConfig.cmake next to my own library's
FooConfig.cmake.
Also, in the compatibility mode, it's not my goal to get a 1-on-1 match
with FindPython.cmake. For my needs, I only require what
FindInterp.cmake and FindLibs.cmake can deliver.
Now my questions to you are:
- What do you think of these approaches?
- What's the most CMake-esque approach?
- How can I improve this?
- Any better names for FindPythonCompat.cmake? FindPythonShim.cmake?
FindPythonForward.cmake?
Thanks for your feedback,
Bram
unset(_PythonCompat_ARGS)
if(PythonCompat_FIND_VERSION)
list(APPEND _PythonCompat_ARGS ${PythonCompat_FIND_VERSION})
endif()
if(PythonCompat_FIND_VERSION_EXACT)
list(APPEND _PythonCompat_ARGS EXACT)
endif()
if(PythonCompat_FIND_QUIETLY)
list(APPEND _PythonCompat_ARGS QUIET)
endif()
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.12)
# Cmake 3.12 has FindPython.cmake, so we can simply forward to it
unset(_PythonCompat_COMPONENTS)
unset(_PythonCompat_OPTIONAL_COMPONENTS)
foreach(_PythonCompat_COMPONENT ${PythonCompat_FIND_COMPONENTS})
if(PythonCompat_FIND_REQUIRED_${_PythonCompat_COMPONENT})
list(APPEND _PythonCompat_COMPONENTS "${_PythonCompat_COMPONENT}")
else()
list(APPEND _PythonCompat_OPTIONAL_COMPONENTS
"${_PythonCompat_COMPONENT}")
endif()
endforeach()
find_package(Python ${_PythonCompat_ARGS}
COMPONENTS ${_PythonCompat_COMPONENTS}
OPTIONAL_COMPONENTS ${_PythonCompat_OPTIONAL_COMPONENTS})
set(PythonCompat_FOUND ${Python_FOUND})
return()
endif()
if(NOT PythonCompat_FIND_COMPONENTS)
set(PythonCompat_FIND_COMPONENTS Interpreter)
set(PythonCompat_FIND_REQUIRED_Interpreter TRUE)
endif()
set(_PythonCompat_REQUIRED_VARS)
if(DEFINED PythonCompat_FIND_REQUIRED_Interpreter)
if(Python_EXECUTABLE AND NOT PYTHON_EXECUTABLE)
set(PYTHON_EXECUTABLE ${Python_EXECUTABLE} CACHE FILEPATH
"Path to a program." FORCE)
endif()
find_package(PythonInterp ${_PythonCompat_ARGS})
set(Python_Interpreter_FOUND ${PYTHONINTERP_FOUND})
set(Python_EXECUTABLE ${PYTHON_EXECUTABLE})
set(Python_VERSION ${PYTHON_VERSION_STRING})
set(Python_VERSION_MAJOR ${PYTHON_VERSION_MAJOR})
set(Python_VERSION_MINOR ${PYTHON_VERSION_MINOR})
set(Python_VERSION_PATCH ${PYTHON_VERSION_PATCH})
if(TARGET Python::Interpreter AND PYTHONINTERP_FOUND)
add_executable (Python::Interpreter IMPORTED)
set_property(TARGET Python::Interpreter PROPERTY
IMPORTED_LOCATION "${PYTHON_EXECUTABLE}")
endif()
if(PythonCompat_FIND_REQUIRED_Interpreter)
list(APPEND _PythonCompat_REQUIRED_VARS PYTHON_EXECUTABLE)
endif()
endif()
if(DEFINED PythonCompat_FIND_REQUIRED_Development)
find_package(PythonLibs ${_PythonCompat_ARGS})
set(Python_Development_FOUND ${PYTHONLIBS_FOUND})
set(Python_INCLUDE_DIRS ${PYTHON_INCLUDE_DIRS})
set(Python_LIBRARIES ${PYTHON_LIBRARIES})
#set(Python_LIBRARY_DIRS ${PYTHON_EXECUTABLE})
#set(Python_RUNTIME_LIBRARY_DIRS ${PYTHON_EXECUTABLE})
set(Python_INCLUDE_DIR ${PYTHON_INCLUDE_DIR})
set(Python_LIBRARY_RELEASE ${PYTHON_LIBRARY_RELEASE})
set(Python_LIBRARY_DEBUG ${PYTHON_DEBUG_LIBRARY})
if(NOT TARGET Python::Python AND PYTHONLIBS_FOUND)
Re: [CMake] how to deprecate a target?
Hi Petr, Marc, I guess I could generate a linker warning, it's indeed not-so-nice, but might do the trick ... It seems aliases are only possible on global imported targets. Mine aren't (which is by default I guess). It's probably not a great idea to make them global ... Thanks for the suggestions! Bram On 7/2/2018 10:20, Marc CHEVRIER wrote: FYI: Starting with CMake 3.11, it is now possible to define an alias of an imported target. Le lun. 2 juil. 2018 à 09:27, Petr Kmoch <mailto:petr.km...@gmail.com>> a écrit : Hi Bram. Wild idea: could you also define a non-namespaced target `foo` and craft it such that linking against it generates a linker warning? Something like "Warning: symbol `Using_just_foo_is_deprecated_use_Foo_foo_instead` defined twice, ignoring weak definition." Petr On 2 July 2018 at 00:11, Bram de Greve mailto:b...@cocamware.com>> wrote: That is unfortunate ... do you know any not-so-nice ways? So, what would you recommend here? I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that nicely with variable watches. But what about the target names? If I want to guarantee a seamless transition period, I should opt to keep using the "foo" target names. But then there's no way to "upgrade" to "Foo::foo" targets without breakage, since there's no deprecation strategy. And I can't use target aliases, since that is not allowed on imported targets. To answer my own question, I think the best thing is to move to the "Foo::foo" targets right now. There's at least one downstream package that will be hurt by this, but the damage is less than waiting for everyone to have moved to the "foo" target first. Best, Bram. On 6/29/2018 20:22, Robert Maynard wrote: I am not aware of a nice way to setup CMake to error out if a user links to `foo` instead of `Foo::foo`. On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve mailto:b...@cocamware.com>> wrote: Hi all, Consider this situation. I'm building a Foo packaged, to be used by a Bar project. Foo used to export its target as simply foo. Now it exports its target as Foo::foo. Bar contains this: add_library(bar ...) target_link_libraries(bar foo) This of course must now be: add_library(bar ...) target_link_libraries(bar Foo::foo) But if bar still links to the foo instead of Foo::foo, then CMake doesn't really complain. foo doesn't exist, but configures and generates just fine. Of course, you'll face strange build errors, from which it isn't immediately apparent what's causing this ... How can I make sure CMake will complain loudly when bar still links to foo? Thanks, Bram. -- Powered by www.kitware.com <http://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 -- Powered by www.kitware.com <http://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:
Re: [CMake] how to deprecate a target?
That is unfortunate ... do you know any not-so-nice ways? So, what would you recommend here? I'm deprecating the old ways to use the Foo package (using Foo_LIBRARIES and Foo_INCLUDE_DIRS. You know, the cmake 2.x way of things). I can do that nicely with variable watches. But what about the target names? If I want to guarantee a seamless transition period, I should opt to keep using the "foo" target names. But then there's no way to "upgrade" to "Foo::foo" targets without breakage, since there's no deprecation strategy. And I can't use target aliases, since that is not allowed on imported targets. To answer my own question, I think the best thing is to move to the "Foo::foo" targets right now. There's at least one downstream package that will be hurt by this, but the damage is less than waiting for everyone to have moved to the "foo" target first. Best, Bram. On 6/29/2018 20:22, Robert Maynard wrote: I am not aware of a nice way to setup CMake to error out if a user links to `foo` instead of `Foo::foo`. On Fri, Jun 29, 2018 at 2:05 AM Bram de Greve wrote: Hi all, Consider this situation. I'm building a Foo packaged, to be used by a Bar project. Foo used to export its target as simply foo. Now it exports its target as Foo::foo. Bar contains this: add_library(bar ...) target_link_libraries(bar foo) This of course must now be: add_library(bar ...) target_link_libraries(bar Foo::foo) But if bar still links to the foo instead of Foo::foo, then CMake doesn't really complain. foo doesn't exist, but configures and generates just fine. Of course, you'll face strange build errors, from which it isn't immediately apparent what's causing this ... How can I make sure CMake will complain loudly when bar still links to foo? Thanks, Bram. -- 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 -- 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] how to deprecate a target?
Hi all, Consider this situation. I'm building a Foo packaged, to be used by a Bar project. Foo used to export its target as simply foo. Now it exports its target as Foo::foo. Bar contains this: add_library(bar ...) target_link_libraries(bar foo) This of course must now be: add_library(bar ...) target_link_libraries(bar Foo::foo) But if bar still links to the foo instead of Foo::foo, then CMake doesn't really complain. foo doesn't exist, but configures and generates just fine. Of course, you'll face strange build errors, from which it isn't immediately apparent what's causing this ... How can I make sure CMake will complain loudly when bar still links to foo? Thanks, Bram. -- 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] multiple cvs updates for continuous build
Hi, I have a large project that combines the sources of different CVS repositories/projects in one build. I would like to perform a continuous build on this, but AFAIK it's possible to do only one cvs update on this. So the continuous build would listen to only one of the CVS projects. Is there a way I would be able to extend this listener mechanism to the different CVS projects? Thanks in advance, Bram ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multiple cvs updates for continuous build
Clinton Stimpson wrote:
You can do it like this:
WHILE (${CTEST_ELAPSED_TIME} LESS 36000)
SET (START_TIME ${CTEST_ELAPSED_TIME})
CTEST_START (Continuous)
CTEST_UPDATE (SOURCE ${CTEST_SOURCE_DIRECTORY} RETURN_VALUE res1)
CTEST_UPDATE (SOURCE ${OTHER_SOURCE_DIRECTORY} RETURN_VALUE res2)
IF(res1 GREATER 0 OR res2 GREATER 0)
CTEST_CONFIGURE()
CTEST_BUILD()
CTEST_TEST()
CTEST_SUBMIT()
Clint
Thanks Clint, I'll try this tomorrow!
When used with CDash, will this combine the reported update?
Bram
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] timeout on total test time?
Thanks for the info, I'll use a workaround then ... Bram Bill Hoffman wrote: Bram de Greve wrote: Hello, Can anyone answer this question? I've tried the --test-timeout switch on ctest, but it seems to have no effect. Thanks, Bram Hi, Is it possible to specify the total amount of time CTest may spend on running the tests? With CTEST_TIMEOUT, you can set the time CTest may spend on each test, but that's not really what I'm looking for. This is not currently possible. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] continuous build on a branch?
Weird, because that's exactly what I'm trying.
I'll have a closer look.
Bram
Bill Hoffman wrote:
Bram de Greve wrote:
Hello,
Does anyone know how I can fix this? I need a continuous build on a
branch, but it keeps updating to the main branch
This script does that:
http://www.cdash.org/CDash/viewNotes.php?buildid=263229
Key parts are here:
if(NOT EXISTS ${CTEST_DASHBOARD_ROOT}/${CTEST_DIR_NAME})
set(CTEST_CHECKOUT_COMMAND \${CTEST_UPDATE_COMMAND}\ -q -z3
-d:pserver:anon...@www.cmake.org:/cvsroot/CMake co -d
\${CTEST_DIR_NAME}\ -D yesterday -r CMake-2-6 ${CTEST_MODULE_NAME})
endif(NOT EXISTS ${CTEST_DASHBOARD_ROOT}/${CTEST_DIR_NAME})
set(CTEST_UPDATE_COMMAND ${CVS})
set(CTEST_UPDATE_OPTIONS -d -P -r CMake-2-6)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] timeout on total test time?
Hello, Can anyone answer this question? I've tried the --test-timeout switch on ctest, but it seems to have no effect. Thanks, Bram Hi, Is it possible to specify the total amount of time CTest may spend on running the tests? With CTEST_TIMEOUT, you can set the time CTest may spend on each test, but that's not really what I'm looking for. Thanks Bram ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] continuous build on a branch?
Hi,
How can I set up a continuous build on a branch?
I've tried setting CTEST_UPDATE_OPTIONS to include the branch name, but
it keeps removing the stickyness and update to the main branch.
set(CTEST_CVS_CHECKOUT ${CTEST_CVS_COMMAND} -d:pserver:f...@bar.com/baz
co -r branchname foobar)
set(CTEST_UPDATE_OPTIONS -dP -r branchname)
Thanks,
Bram
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] timeout on total test time?
Hi, Is it possible to specify the total amount of time CTest may spend on running the tests? With CTEST_TIMEOUT, you can set the time CTest may spend on each test, but that's not really what I'm looking for. Thanks Bram ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] how to set 2 additional compile flags on target (VS2005)
Hi,
I'm trying to use precompiled headers with VS2005. Therefore, I need to
set on the target two additional compile flags: /Yu with the header to
be precompiled, and /Fp with the path of the resulting PCH.
But whatever I try, cmake will only set one of them.
The following will only set the second compile flag. in this case /Fp.
If I reverse the lines, it will set /Yu.
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile}
COMPILE_FLAGS /Fp${pchpath}
)
If I put both compile flags on one line as following, it is not accepted
by CMake as there's an incorrect number of arguments:
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile} /Fp${pchpath}
)
Splitting it into two statements as following, has the same effect (only
setting the second one)
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Yu${hdrfile}
)
set_target_properties(
${target}
PROPERTIES
COMPILE_FLAGS /Fp${pchpath}
)
Using set_property with APPEND, has the effect that it concatenates both
flags with a semicolon, something like /Yufoobar.h;/Fpfoobar.pch, so
that VS thinks the header to be precompiled is called
foobar.h;/Fpfoobar.pch. Err, wrong =)
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Yu${hdrfile} /Fp${pchpath})
It even has this same concatenation effect when I split it into two
statements:
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Fp${pchpath})
set_property(
TARGET ${target}
APPEND PROPERTY
COMPILE_FLAGS /Yu${hdrfile})
And when I leave out the APPEND, we're back to square one where it only
sets the second compiler flag:
set_property(
TARGET ${target}
PROPERTY
COMPILE_FLAGS /Fp${pchpath})
set_property(
TARGET ${target}
PROPERTY
COMPILE_FLAGS /Yu${hdrfile})
So, my question obviously is: what's the proper way to set TWO (or more)
additional compiler flags on na target.
Thanks in advance,
Bram
PS: Technically, it's not really necessary to set /Fp, as the default is
fine, but it still strikes me as cumbersome.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] assembly files with masm in vs2005 64bit
Hi Bill, Alex, I tried getting it building using custom commands, but that seems to mean of adding an obj file as source file (read: being listed in the project file) that gets customly build with an assembler. Apart from being ugly, it didn't seem to work either. But in retrospect, that might be because of the same missing def file I was struggling with for the nmake build. As Bill says, what I really would like to see is visual studio compiling the asm file where the asm file itself is considered as the source file. Bill, is this something that is planned to be worked on? Alex, your cmake files work great for the nmake build. Is it allowed to ship these files with the project that needs them (and to check them into the svn repository), as long as they are not part of the cmake distribution yet? Regards, Bram 2008/10/30 Bill Hoffman [EMAIL PROTECTED] Alexander Neundorf wrote: On Wednesday 29 October 2008, Bill Hoffman wrote: Bram de Greve wrote: So thumbs up for the nmake side of the story. Thanks for your help. So, now there's only the visual studio project generation left ... Can this be fixed on script level as well? Or does it need binary intervention ? I am pretty sure, this would require C++ changes to support. I thought languages beside C/C++ are supported in these generators via custom commands ? They are, but it is not going to be real support, and is under tested, so I am thinking it won't work... I would think people would want visual studio actually compile the asm stuff like it does the c/C++. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] assembly files with masm in vs2005 64bit
Hi Alex, 2008/10/28 Alexander Neundorf [EMAIL PROTECTED] Hi Bram, That still leaves open the issue of the visual studio projects not including any build rule for the assembly. So it's not a build rule that fails, but it is simply missing ... Hmm, I think Bill or Brad can help better with this. Ok. Please check if nmake works out of the box if you use the two attached files and let me know. The location of the C compiler is now used as additional search path for the assembler and it also checks if a 32 or 64 bit compiler are used and searches for ml.exe and ml64.exe respectively. Technically, it already worked on second iteration. It already did find ml64 automatically. The problem was that the symbols in the asm file didn't get exported in the DLL. That was not a problem of CMake but of a missing .def file (beats me why it did work with the handcrafted solution though). So thumbs up for the nmake side of the story. Thanks for your help. So, now there's only the visual studio project generation left ... Can this be fixed on script level as well? Or does it need binary intervention ? Thanks, Bram -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] assembly files with masm in vs2005 64bit
Message: 7 Date: Mon, 27 Oct 2008 23:06:22 +0100 From: Alexander Neundorf [EMAIL PROTECTED] Subject: Re: [CMake] assembly files with masm in vs2005 64bit To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-6 Hi Bram, Please test the attached files. They still shouldn't find ml64.exe, but I added some debug output I'd like to see. So, please use them and post the output. In which directory is ml64.exe on your system ? Alex Hi Alex, On the nmake front: the problem with the unresolved symbols is one of building a DLL instead of static library, and the symbols don't get exported ... So, at least, I'm successful at using masm with nmake. That still leaves open the issue of the visual studio projects not including any build rule for the assembly. So it's not a build rule that fails, but it is simply missing ... Here's the output you requested for Visual Studio 2005 Win64 generator: Check for working C compiler: cl Check for working C compiler: cl -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler: cl Check for working CXX compiler: cl -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done CMAKE_C_COMPILER_PATH: - CMAKE_C_COMPILER: -cl TOOLCHAIN LOCATION: - Didn't find assembler Loaded CMakeASM_MASMInformation - ASM_MASM support is still experimental, please report issues Configuring done For comparison, this is what I get using the nmake generator (which immediately gives you the locations requested for. it can be assumed ml64.exe is next to cl.exe): The C compiler identification is MSVC The CXX compiler identification is MSVC Check for CL compiler version Check for CL compiler version - 1400 Check if this is a free VC compiler Check if this is a free VC compiler - no Check CL platform Check CL platform - 64 bit Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done CMAKE_C_COMPILER_PATH: - CMAKE_C_COMPILER: -C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe TOOLCHAIN LOCATION: -C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64 Found assembler: C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/ml64.exe Loaded CMakeASM_MASMInformation - ASM_MASM support is still experimental, please report issues Thanks for your help, Bram -- hi, i'm a signature viruz, plz set me as your signature and help me spread :) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] assembly files with masm in vs2005 64bit
Hi Alexander,
Thanks for your quick response!
2008/10/24 Alexander Neundorf [EMAIL PROTECTED]
On Friday 24 October 2008, Alexander Neundorf wrote:
Yes, I think you're the first one who tries that.
Alright! =)
This is the custom build step I need to perform (copy pasted from a
handcrafted solution file):
ml64 -c -Zi -Flfoobar.lst -FRfoobar.sbr -Fofoobar.obj
foobar.asm
Are -Fl and -FR necessary or does it also work without them ?
The foobar.lst one isn't necessary. The second one only is necessary if
browse information is needed. Not sure if that is the case ...
Ok, it was a bit faster (waiting for Qt to build...)
So, please put the three attached files into the cmake Modules/ directory
and
use
ENABLE_LANGUAGE(ASM-MASM)
This should find ml64.exe .
If it doesn't, try hardcoding it for now in
CMakeDetermineASM-MASMCompiler.cmake.
Let me know which problems you hit.
Alex
I already tried something similar, though I got stuck halfway.
Anyway, I dropped in your files in my source directory, which I've added to
the module path as follows:
list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR})
cmake seems to pick them up alright. But the result doesn't seem to work.
I've tried it in two ways:
1. Using the Visual Studio 2005 Win64 generator to create solution files
- Here the minor problem is, as you already predicted, that it doesn't
automatically detect ml64.exe but a manual configuration of the variable
does help
- the asm file appears in the project, but there doesn't seem to be any
build rule associated with it. Nor as a custom build step in the properties
pages, nor as a CMake rule
- as a result, the asm file does not get build, yielding some unresolved
symbols at linking time
2. Using nmake from the VS2005 x64 command prompt
- The first issue is that nmake doesn't like the dashes in variable/macro
names. So I had to replace it by an underscore in the dialect strings:
SET(ASM_DIALECT _MASM)
- Again, no build rule for the asm file gets inserted, resulting again in
unresolved symbols.
- Then it dawned to me that there were other places to replace -MASM by
_MASM: in enable_language, when setting the asm file's language property,
and also in the filenames of the cmake files you gave me.
- Now, build rules are created, but no obj files are being build. I had to
move SOURCE to the end:
SET(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT
CMAKE_ASM${ASM_DIALECT}_COMPILER FLAGS /c /Fo OBJECT SOURCE)
- Now, obj file is build, it is enlisted in objects.rsp, but the linker
still can't find its symbols ...
But at least, we're one or two steps closer =)
1. Why doesn't the asm file get any rules in the solution file?
2. Why are the symbols still unresolved in the nmake situation?
Cheers,
Bram
--
hi, i'm a signature viruz, plz set me as your signature and help me spread
:)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] assembly files with masm in vs2005 64bit
Hi,
I'm trying to build some library with vs2005 64bit using CMake. This
library uses some assembly and as the 64 bit mode of vs2005 doesn't support
inline assembly, and external call to MASM is necessary. However, I'm
having troubles getting this working.
I've googled on cmake + masm, but that wasn't of much help.
This is the custom build step I need to perform (copy pasted from a
handcrafted solution file):
ml64 -c -Zi -Flfoobar.lst -FRfoobar.sbr -Fofoobar.obj foobar.asm
In my CMakeLists.txt i have something like:
enable_language(ASM)
set_source_files_property(foobar.asm LANGUAGE ASM)
list(APPEND lass_SRCS ${sourcepath})
add_library(mylib foobar.asm ...)
The problems I'm facing are:
1. ml64 can't be found as assembler. Though I can explicitly set its path
using the advanced view
2. foobar.asm does not get any custom build step, nor any cmake rule
Does you have some advance how to solve this issue, as it is a real
showstopper ...
Thanks in advance,
Bram
--
hi, i'm a signature viruz, plz set me as your signature and help me spread
:)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
