Re: [CMake] build step is not thread-safe for CMake

2020-02-10 Thread Kyle Edwards via CMake
On Mon, 2020-02-10 at 12:49 +, hex wrote:
> hello,
> 
> My build step is not thread-safe (the instruction in the COMMAND
> part). Every build step depends on one source file:
> 
> add_custom_command(
>     DEPENDS on_source.file
>     OUTPUT
>     object_file_for_source_file
>     COMMAND not-thread-safe-compiler --build on_source.file
>     COMMENT
>             "Building Source object"
> )
> 
> add_custom_target DEPENDS on OUTPUT from all custom command's, but in
> order to prevent parallel execution when cmake is called:
> 
> cmake --build . --target all -j30
> 
> I need to build each step in any order, but still not as a dependency
> as this would trigger unnecessary recompilation. Using
> MAIN_DEPENDENCY defines hierarchical dependency, but this won't help
> in this situation.
> 
> I cannot figure out how to prevent parallel execution of COMMAND in
> CMake. The only option I see is a single command
> 
> add_custom_target(tgt
>     DEPENDS on_all_source.files
>     COMMAND not-thread-safe-compiler --build on_source1.file
>     COMMAND not-thread-safe-compiler --build on_source2.file
>     COMMAND not-thread-safe-compiler --build on_source3.file
>     . . .
>     COMMENT
>             "Building target"
> )
> 
> this would rebuild every source, though.
> 
> How do I set this up?
> 
> thank you

It sounds like you want order-only dependencies: dependencies the
command waits for before building, but whose changes do not actually
trigger a rebuild. As far as I know, add_custom_command() doesn't have
support for this - perhaps it could be added.

This mailing list is deprecated. Please move further discussion to the
Discourse forum:

https://discourse.cmake.org/c/code/11

Kyle
-- 

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

2019-12-12 Thread Kyle Edwards via CMake
On Thu, 2019-12-12 at 15:15 +0100, René J.V. Bertin wrote:
> 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?

The bootstrap CMake does not have all of the capabilities of the real
CMake - just enough to build CMake itself. It is intended to be used
once to build the real CMake and then immediately discarded.

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:

https://discourse.cmake.org/c/usage

Kyle
-- 

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] Testing an exe with gtest - possible?

2019-11-20 Thread Kyle Edwards via CMake
On Wed, 2019-11-20 at 00:54 +0100, cen wrote:
> Hi
> 
> I have an existing c++ exe project which I want to test with gtest.
> I 
> have not yet found an easy way to keep the project as is and test it 
> directly since gtest insists (obviously) to link against the code
> being 
> tested. I found a smart answer on SO to link against object files
> and 
> that works ok but it's messy and a lot of manual setup after cmake 
> project generation, probably impossible to automate in cmake.
> 
> The other quick way is to change the VS project output to a static
> lib. 
> That also works but is a manual step which again not sure can be 
> automated at all. And there is a bigger issue hidden in here.. I
> can't 
> link to this lib due to dual main() entry point.
> 
> So unless there is some smart workaround to keep project as an exe
> and 
> get gtest to work, I guess the only remaining option is to separate
> the 
> main() into a small bootstrap exe and then link against the rest of
> the 
> program (which contains the actual testable logic) as a lib. Finally,
> if 
> I understand correctly, using target_link_libraries will
> automatically 
> set up the two projects as dependent and lib will always get built 
> before the main is run.

Check out the $ generator expression. This will let
you link directly against the object files built for the executable.

This mailing list is deprecated. Please post further discussion to
Discourse:

https://discourse.cmake.org/c/code

Kyle
-- 

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-developers] generator expression in install RENAME

2019-10-29 Thread Kyle Edwards via cmake-developers
Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues
to request support for this.

Kyle

On Tue, Oct 29, 2019 at 9:58 AM Nicolas Desprès
 wrote:
>
> Hi there,
>
> Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part 
> of an install command.
>
> Would that be possible to enable generator expression in the RENAME part as 
> well?
>
> The use-case is for the TARGET_FILE_BASE_NAME expression.
>
> Cheers,
>
> --
> Nicolas Desprès
>
> --
>
> 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-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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] Policy Stack within Macros/Functions

2019-10-21 Thread Kyle Edwards via CMake
On Mon, 2019-10-21 at 21:39 +0200, Sérgio Agostinho wrote:
> For further users with the same problem, you likely do not need need
> to invoke cmake_policy(PUSH)/cmake_policy(POP) from your shipped
> Config file, so just delete them and set whatever policies you need
> without concerns.

This has the caveat that CMP0011 must be set to NEW for it to work
(which should be the case with any sane project - CMP0011 was
introduced in 2.6, the oldest version recognized by
cmake_minimum_required().)

Kyle
-- 

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] Concerning ninja -v

2019-10-21 Thread Kyle Edwards via CMake
On Mon, 2019-10-21 at 10:23 +0100, David Aldrich wrote:
> I have a simple CMake project with subdirectories:
> 
> cmake_minimum_required(VERSION 3.10)
> project(MyProject VERSION 1.0.0)
> 
> set(CMAKE_VERBOSE_MAKEFILE ON CACHE BOOL "ON")
> 
> add_subdirectory(say-hello)
> add_subdirectory(hello-exe)
> 
> Will the 'CMAKE_VERBOSE_MAKEFILE' option be inherited by the
> CMakeLists.txt files in the subdirectories?
> 
> I want to run ninja with the '-v' option for verbosity but the above
> 'set' command is not achieving this. What do I need to do
> differently?

Does just invoking ninja with -v not show verbosity? That should do it.
I don't believe CMAKE_VERBOSE_MAKEFILE affects Ninja builds.

Kyle
-- 

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] Policy Stack within Macros/Functions

2019-10-21 Thread Kyle Edwards via CMake
On Sun, 2019-10-20 at 19:25 +0200, Sérgio Agostinho wrote:
> Hey everyone,
> 
> I’m shipping a config file for my library and inside I set push/pop
> specific policies so that me and the consumers of my library can
> target different policies without us clashing against each other.
> However I’m struggling with cmake_policy(PUSH)/cmake_policy(POP) once
> they are invoked from macro/functions.
> 
> Here’s a minimal failure example illustrating my problem
> 
> 
> project(pcl-config-test)
> cmake_minimum_required(VERSION 3.5)
> 
> cmake_policy(PUSH)
> 
> macro(return_early)
>   # clean up code
>   cmake_policy(POP)
>   return()
> endmacro()
> 
> # 1. do a bunch of things. invoke a couple of macros/functions
> # from within other macros/functions, etc...
> 
> # 2. some error occurs
> if(ERROR)
>   return_early()
> endif()
> 
> # 3. Everything went well
> cmake_policy(POP)
> This produces the following output
> 
> 
> CMake Error at CMakeLists.txt:27 (my_macro):
>   cmake_policy POP without matching PUSH
> 
> CMake Error in CMakeLists.txt:
>   cmake_policy PUSH without matching POP
> 
> -- Configuring incomplete, errors occurred!
> I was counting on the policy stack being preserved for at least
> macros, but that is not the case.
> 
> Is there a way for me to return early from my config file from within
> macros?

If you're trying to set policies within a function, set them at the
module level rather than at the function level. The module-level policy
settings will automatically be pushed when you call the function. That
way, there will be no need to do cmake_policy(POP) within
return_early().

Kyle
-- 

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] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)

2019-10-11 Thread Kyle Edwards via CMake
On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin
 wrote:
> The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, 
> COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped."

This is by far the most likely reason. We added this restriction
because we don't want files that have different COMPILE_FLAGS etc. to
be lumped together in a unity file. We decided that this was good
enough as a first past, but the way forward is to intelligently group
together files that have the same COMPILE_OPTIONS,
COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES.

Kyle
-- 

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] HOWTO declare component inter-dependencies in multi-component packages

2019-10-03 Thread Kyle Edwards via CMake
On Thu, 2019-10-03 at 17:08 -0400, stefan wrote:
> Yes, that is exactly what I'm trying to do, but it doesn't seem to
> have any effect. That is, `dpkg --info ...` doesn't list the
> additional dependency, and correspondingly, running `apt-get install
> ...` on the component package file will install the package without
> first installing the prerequisite component.
> Consider this declaration:
>   set(CPACK_COMPONENTS_ALL runtime development mstool)
> If I now write
>   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS runtime)
> I will see no effect. That is, the "development" package still does
> not depend on the "runtime" package.
> So I try this:
>   set(CPACK_COMPONENT_DEVELOPMENT_DEPENDS RUNTIME)
> in case capitalization is required. Now the "runtime" component seems
> to get packaged twice (as per the cmake logs), but still no correct
> dependencies.
> Is it time for a bug report ?

Please send us a minimal CMakeLists.txt that reproduces the issue.

Kyle
-- 

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] HOWTO declare component inter-dependencies in multi-component packages

2019-10-03 Thread Kyle Edwards via CMake
On Thu, 2019-10-03 at 16:30 -0400, stefan wrote:
> Hi Kyle,
> thanks for the quick followup.
> On 2019-10-03 4:23 p.m., Kyle Edwards wrote:
> > Please take a look at cpack_add_component():
> > https://cmake.org/cmake/help/latest/module/CPackComponent.html
> I'm not sure what specifically I should be looking for.
> In general my setup is working fine, i.e. my build generates multiple
> packages as expected. They even contain dependencies to external
> packages, as I have set as per the available variables. What I
> haven't been able to express is the component inter-dependency. That
> is, I haven't found a way to make my "development" package depend on
> the "runtime" package (generated from the same build process).
> Sorry for being obtuse.

In particular, please look at the DEPENDS argument of
cpack_add_component():

"DEPENDS lists the components on which this component depends. If this
component is selected, then each of the components listed must also be
selected. The dependency information is encoded within the installer
itself, so that users cannot install inconsistent sets of components."

Kyle
-- 

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] HOWTO declare component inter-dependencies in multi-component packages

2019-10-03 Thread Kyle Edwards via CMake
On Thu, 2019-10-03 at 16:15 -0400, stefan wrote:
> I'm trying to generate (debian) packages for a project of mine using
> cmake. I need to generate multiple components ("runtime",
> "development", etc.). What is the expected way to have the
> "development" package depend on the "runtime" package ?
> I'v been trying to play with the
> CPACK_DEBIAN_ENABLE_COMPONENT_DEPENDS setting, but so far wasn't able
> to have my packages contain the expected dependencies in their
> metadata.
> Thanks,

Please take a look at cpack_add_component():

https://cmake.org/cmake/help/latest/module/CPackComponent.html

Kyle
-- 

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] Single library with both shared and static binaries

2019-09-25 Thread Kyle Edwards via CMake
On Tue, 2019-09-24 at 23:41 +0300, Avraham Shukron wrote:
> Hi!
> 
> I have a library which I want to distribute in both shared object and
> static library forms.
> Is there a modern way to do it without creating two completely
> separate library targets?
> Since I want to be a good CMake citizen I use `target_*` and
> `set_target_properties` as much as possible, and creating two
> different libraries will force me to duplicate that information about
> each one of them.
> 
> I also tries not specifying STATIC/SHARED, and then running cmake
> twice - once with BUILD_SHARED_LIBS=ON and once OFF and then
> installing to the same directory. I got my both .a and .so libraries
> installed, but I couldn't get the Config file correctly for this
> arrangement.
> 
> So - what is the community-recommended pattern to do this?

Unfortunately, the recommendation is to do exactly what you don't want
to do: create a shared target and a static target.

To make this slightly simpler, you can use functions to de-duplicate
the target_* and set_target_properties calls:

function(create_foo_target name type)
  add_library(${name} ${type} foo.c foo.h)
  set_target_properties(${name} OUTPUT_NAME foo)
endfunction()

create_foo_target(foo_shared SHARED)
create_foo_target(foo_static STATIC)

Kyle
-- 

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-developers] Proposal: Using smart pointers to own dynamically allocated memory

2019-09-13 Thread Kyle Edwards via cmake-developers
On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
> Hi,
> 
> I am a C++ developer and a modern-C++ enthusiast. In the interest of
> modernizing the codebase, I propose using smart pointers to handle
> dynamically allocated memory. I would like to get the feedback from
> the developers if this change is planned/attempted/desirable or
> inapplicable for CMake.
> 
> Currently, in the master branch (limiting to the Source directory):
> - delete expression appears 127 times (2 of those are false
> positives).
> $ grep -Er 'delete(\[\])? \S+;' Source | wc -l
>    127
> - cmDeleteAll function (a helper to delete a Range of objects) is
> used 40 times.
> $ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l
> 40
> - [Skipping the `free` stats. I can investigate that if required.]
> 
> Many of these are great candidates for `std::unique_ptr`. This can
> reduce the destructors of many classes to default, and in some cases
> achieve the rule of zero. This aligns well with the "Resource
> management" section of the CppCoreGuidelines.
> However, it might be impractical to replace some occurrences, like
> the
> interfaces with C libraries.
> 
> I have pushed some sample commits to
> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.
> 
> One drawback I noticed while changing some members to use smart
> pointers is the boilerplate required to expose them to the callers.
> There might be a cleaner way than passing references to smart
> pointers. I would like to discuss those options also, if possible.
> 
> If this is something I can pursue, I would appreciate a review of my
> changes to better suit the project.

We have already made lots of progress in replacing manual delete's with
std::unique_ptr's, and completing this modernization has been a goal of
ours since we switched to C++11. I would very strongly encourage you to
open a merge request with any progress you've made in this regard.

Kyle
-- 

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


Re: [CMake] Preventing multiple definitions of metaObject methods

2019-09-13 Thread Kyle Edwards via CMake
On Fri, 2019-09-13 at 15:25 +, Stephen Morris wrote:
> Suppose I have a class that derives from QObject, and contains the
> Q_OBJECT macro in its header file. When I compile it using AUTOMOC
> enabled, a "moc_myClass.cpp" file is created; if I manually include
> that file at the end of my 'myClass.cpp" file, then the moc file will
> be compiled there, otherwise CMake will take matters into its own
> hands and compile it anyway.
> 
> Now suppose make my class into a static library. The static library
> now contains the object code generated when moc_myClass.cpp was
> compiled.
> 
> I now include my static library from an application. Unless I enable
> AUTOMOC again, then I get a compilation error when Q_OBJECT is
> encountered. If I do enable it, then CMake generates a new
> moc_myClass.cpp file and, since it can't see the place where it was
> included in myClass.cpp, it goes ahead and recompiles it, placing the
> object code alongside the application's other object code.
> 
> Now, when the application links in the static library, it finds two
> definitions of moc_myClass.cpp's object code, and gives a multiple
> definition error.
> 
> All the ways I've come up with so far to work around this are so
> hacky that I'm embarrassed to mention them. There must be a proper
> way to handle this situation. Please can someone advise me what it
> is?
> 
> (N.B. I've been doing this for years with dynamic libraries are never
> encountered a problem, presumably because there the application
> doesn't get to see the inner workings of the library's object code.
> This issue does seem to be specific to static libraries, of which I
> have little prior experience).

Stephen,

Could you post a minimally reproducible example with CMakeLists.txt and
accompanying source code? I am currently working on a Qt-based project
with static libraries and have not encountered this issue.

Kyle
-- 

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] Setting RPATH lookup on macOS

2019-09-11 Thread Kyle Edwards via CMake
On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
> 
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath. 
> 
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
> 
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
> 
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
> 
> 
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
> 
> Help

Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?

https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html

Kyle
-- 

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] Should header files be listed for a target?

2019-09-11 Thread Kyle Edwards via CMake
On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> 
> 
> On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards  m> wrote:
> > You can list them or not list them. CMake will recognize them as
> > header
> > files and ignore them (not attempt to compile them.) It's a matter
> > of
> > personal preference. CMake's own CMake script lists them, but there
> > are
> > plenty of projects that don't and work just fine.
> And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> care about headers?

Yes, the headers are more important for IDE generators than they are
for Make/Ninja (though, AFAIK, they still don't affect the build, just
the files that the developer sees in the generated project in the IDE.)

Kyle
-- 

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] Should header files be listed for a target?

2019-09-11 Thread Kyle Edwards via CMake
On Wed, 2019-09-11 at 21:40 +0300, Avraham Shukron wrote:
> Hi!
> 
> I'm pretty new to cmake and I came across a question which I could
> not find any information about in the official documentation or blog
> posts.
> 
> When adding a target through add_library / add_executable - should
> the header files of the target also be listed?
> The question also applies to target_sources I guess.
> 
> On one hand - as far as I can tell it compiles perfectly fine without
> doing so, and the implicit dependency is also recognized (e.g if the
> header changes - the target will be recompiled)
> In addition most of the online examples do not list headers.
> 
> On the other hand - it seems wrong not to list them. They ARE part of
> the target, even if they do not passed to the compiler directly.
> I can also assume that some IDEs will want to know about the
> existence of these headers and their relationship with the target.
> 
> So what is the correct answer? should header files be listed as part
> of the target?

You can list them or not list them. CMake will recognize them as header
files and ignore them (not attempt to compile them.) It's a matter of
personal preference. CMake's own CMake script lists them, but there are
plenty of projects that don't and work just fine.

> Another question - how does cmake know to create the
> dependency between the target and the header file, even when it is
> not listed explicitly?

It uses GCC's -MD and -MF options (and the equivalents for other
compilers), which spits out the header dependency information.

Kyle
-- 

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] try_compile with multiple include directories

2019-09-09 Thread Kyle Edwards via CMake
On Sun, 2019-09-08 at 14:07 -0500, Isuru Fernando wrote:
> Hello,
> 
> I can use the following to get try_compile to include one directory.
> 
> CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"
> 
> How do you use try_compile when I have multiple directories to pass
> to it?
> 
> Isuru

Use a semicolon:

CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1;dir2"

Kyle
-- 

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] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

2019-09-04 Thread Kyle Edwards via CMake
On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt.  A call depth
> of 27491 seems a bit excessive.
> 
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.

Indeed, this was added in 3.14:

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
TH.html
Kyle
-- 

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-developers] escape double quote in generated file

2019-08-30 Thread Kyle Edwards via cmake-developers
On Fri, 2019-08-30 at 19:01 +0300, Eugene Karpov wrote:
> Not working too.
> The failed lines in a generated make file looks like this
> ---
> CMakeFiles/mkflags_test:
>         /usr/bin/cmake -DDEFINITIONS=-
> DAPI=__attribute__((visibility("default"))) -
> DFILENAME=/home/ekarpov/tmp/build/flags.txt -P
> /home/ekarpov/tmp/escape_quotes.cmake
> ---
> 
> And I've tried to double quote the DEFINITIONS parameter that is
> passed to cmake - didn't help.

Please try adding the VERBATIM option to add_custom_target():

https://cmake.org/cmake/help/latest/command/add_custom_target.html

Kyle
-- 

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


Re: [cmake-developers] escape double quote in generated file

2019-08-30 Thread Kyle Edwards via cmake-developers
On Fri, 2019-08-30 at 17:54 +0300, Eugene Karpov wrote:
> I've tried this. But then it fails to compile due to `INTERFACE
> API=${API_EXPORT_MACRO}` target compile definition.

Ah right, you want the file contents to be escaped while the compile
flags are not. My next suggestion was going to be to use a generator
expression that replaces `"` with `\"`, but there does not appear to be
a "string replace" genex. In that case, I would suggest using
add_custom_command()/add_custom_target() to call a cmake -P script
which escapes the quotes and writes the file. For example:

set(_compile_definitions
"$")
set(_compile_definitions "$<$:-
D$\n>")
add_custom_target(mkflags_${_target} COMMAND ${CMAKE_COMMAND} "-
DDEFINITIONS=${_compile_definitions}" "-DFILENAME=${_filename}" -P
path/to/script.cmake BYPRODUCTS "${_filename}")

And then the script would look like:

string(REPLACE "\"" "\\\"" DEFINITIONS "${DEFINITIONS}")
file(WRITE "${FILENAME}" "${DEFINITIONS}")

Kyle
-- 

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


Re: [cmake-developers] escape double quote in generated file

2019-08-30 Thread Kyle Edwards via cmake-developers
On Fri, 2019-08-30 at 17:36 +0300, Eugene Karpov wrote:
> Hello all,
> 
> I'm working on a cross platform project. On Ubuntu I would like to
> save all the compiler options, definitions and other complier related
> stuff to a generated file to use it later for precompiled header
> generation.
> My issue is that I have to specify a macro that contain double quotes
> for g++ compiler visibility attribute. When I generate a file with
> double quotes they are not escaped. I also tried to use
> `string(replace "\"" "\\\""...)` without effect.
> I've made simple two files project of a shared library to show the
> issue. It has only target compile definitions for simplicity.
> 
> - CMakeLists.txt --
> cmake_minimum_required(VERSION 3.14)
> set(target test)
> project(${target})
> if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
>     set(API_IMPORT_MACRO "__attribute__((visibility(\"default\")))")
>     set(API_EXPORT_MACRO "__attribute__((visibility(\"default\")))")

The quotes here need to be double-escaped, like so:

set(API_IMPORT_MACRO "__attribute__((visibility(\\\"default\\\")))")
set(API_EXPORT_MACRO "__attribute__((visibility(\\\"default\\\")))")

Kyle
-- 

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


Re: [CMake] modify cmake build arguments

2019-08-29 Thread Kyle Edwards via CMake
On Thu, 2019-08-29 at 18:27 +0100, hex wrote:
> hello community,
> 
> CMake builds a C project with gcc -o target_name. I have a compiler
> very similar to GCC and I am trying configure CMake C language for
> it.
> 
> The compiler does not support the -o argument when linking objects. I
> wonder if there is a way to remove or modify this argument, maybe
> through one of the properties on targets?
> 
> thank you

Your best bet would be to modify the CMake source code to support your
compiler. (Upstreaming your changes would be welcome.)

As a matter of interest, what does it use instead of -o?

Kyle
-- 

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 Release Candidate Builds Available for Ubuntu

2019-06-07 Thread Kyle Edwards via CMake
All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle
-- 

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] CMake Release Candidate Builds Available for Ubuntu

2019-06-07 Thread Kyle Edwards via cmake-developers
All,

I am pleased to announce that we are now offering Ubuntu builds of the
CMake release candidates, in addition to the production releases. The
first available release candidate build is 3.15.0~rc1-0kitware2.

If you would like to receive release candidate builds, follow the
instructions at https://apt.kitware.com/ to add the release candidate
repository to your installation. (Please note that the release
candidates are optional and opt-in - if you don't explicitly add the
release candidate repository, you will only receive production builds.)

In addition, starting with this release candidate, we are now offering
32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the
same as 64-bit - just add the repository to your installation and
install it.

Happy coding!

Kyle
-- 

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


Re: [CMake] General question about regex

2019-06-04 Thread Kyle Edwards via CMake
On Tue, 2019-06-04 at 19:19 +0200, Steven Truppe wrote:
> I found the solution:
>     get_cmake_property(_vars VARIABLES)
>     foreach(_var ${_vars})
>         string(TOUPPER ${lib} lib_upper)
>         if(_var MATCHES "^WITH_LIB_${lib_upper}_EXAMPLE_([A-Za-
> z]+)$")
>           message(STATUS "Number of examples found:
> ${CMAKE_MATCH_COUNT}")
>       message(STATUS "Number 1 found: ${CMAKE_MATCH_0}")
>         endif()
>     endforeach()
> Now i've two problem - the CMAKE_MATCH_0 contains the hole string and
> not only the part the is in the (), i need only the part from the ()
> - is there another command i can use for this ?

CMAKE_MATCH_1

Kyle
-- 

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] General question:

2019-06-04 Thread Kyle Edwards via CMake
On Tue, 2019-06-04 at 17:11 +0200, Steven Truppe wrote:
> I want the output not to be 'in' but 'glade' ...
> 
> 
> On 04.06.19 17:10, Steven Truppe wrote:
> > 
> > Hi everyone again,
> > 
> > 
> > i've the following code:
> > 
> > https://paste.debian.net/1086040/
> > 
> > and i just try to traverse a list and include files whose part of
> > the
> > name are the list entries.
> > 
> > 
> > best regards!
> > 

Please see the foreach() documentation:

https://cmake.org/cmake/help/v3.14/command/foreach.html

I think you want:

foreach(lib IN LISTS libs)

Kyle
-- 

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] Question about regular expressions

2019-06-04 Thread Kyle Edwards via CMake
On Tue, 2019-06-04 at 16:39 +0200, Steven Truppe wrote:
> Hi everyone,
> 
> 
> i had the same question a few days ago but can't rember the command
> (and
> can't find it in the cods):
> 
> I have a regular expression like "WITH_LIB${lib}_EXAMPLE_([A-Za-z]+)"
> and i want the get the content of the found variables in the (), the
> command i used stored them if MATCH_XYZ but i can't exactly rember
> =(.
> 
> 
> best regards!

CMAKE_MATCH_

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MATCH_n.html

Kyle
-- 

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] find_program usage

2019-06-04 Thread Kyle Edwards via CMake
On Tue, 2019-06-04 at 19:38 +0530, vinay kumar Kotegowder wrote:
> The original intent of the snippet is to find the required tool chain
> (On windows : arm-none-eabi-gcc.exe or armclang.exe; On Linix :
> arm-none-eabi-gcc or armclang) path which can later be used to build
> the project.
> 
> I have been trying with find_program and find_path commands.
> My understanding was that it would find the program from root(which
> is
> C: in Windows and / in Linux) and all the sub directories underneath
> it but I learnt from your reply that it is not the case.
> 
> Can this be done? I mean, should it be possible to find the program
> without hard coding the path ?

It is possible to pass hints and paths to find_program() telling it
additional places to look ("it *might* be in C:/MinGW/whatever/bin"),
but other than that, find_program() does not search recursively. See
the find_program() documentation for more details:

https://cmake.org/cmake/help/v3.14/command/find_program.html

Again, for GCC, I strongly recommend that you use a toolchain file,
rather than setting CMAKE_C_COMPILER from inside your project. CMake
does a bunch of checks with the compiler when you first call project(),
which end up no longer being valid if you change CMAKE_C_COMPILER. (I
suppose you could set CMAKE_C_COMPILER from in your project before
calling project(), but I do not recommend this method.) You *can* call
find_program() from inside your toolchain file if you don't want to
hard-code the paths.

Kyle
-- 

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] find_program usage

2019-06-04 Thread Kyle Edwards via CMake
On Tue, 2019-06-04 at 19:07 +0530, vinay kumar Kotegowder wrote:
> Hi Everyone,
> 
> This is simple code running on Windows machine:
> 
> if(WIN32)
>   message(STATUS "On windows")
>   find_program(_TOOL
>   arm-none-eabi-gcc.exe
>   PATHS "C:"
> )
> endif()
> 
> message(STATUS "${_TOOL}")
> 
> Result after executing: cmake -P mycmake.cmake
> 
> -- On windows
> -- _TOOL-NOTFOUND
> 
> Can anyone tell me what is wrong with the usage of "find_program"  ?

find_program() is looking in C:, but not its subdirectories. So, unless
arm-none-eabi-gcc.exe is located directly in C:, CMake won't find it.

As a side note, GCC isn't typically found with find_program(). You most
likely want to write a cross-compiling toolchain file which contains
this location instead. See below for details:

https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html

Kyle
-- 

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] Troubles with macros and STREQUAL

2019-05-31 Thread Kyle Edwards via CMake
On Fri, 2019-05-31 at 20:43 +0200, Steven Truppe wrote:
> macro(bsAddLibrary lib)
>  # get all WITH_LIB varables
>      message(STATUS "${lib}")
> 
>  get_cmake_property(_variables VARIABLES)
>  foreach(_var ${_variables})
> 
> -->> (${lib} is "WITH_LIB_GLAD" but allways return false =(       
> if(_var STREQUAL ${lib})

Should be:

if(_var STREQUAL lib)

due to how if() expands variable references.

https://cmake.org/cmake/help/v3.14/command/if.html#variable-expansion

Kyle
-- 

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] Question about IF and STRINGS

2019-05-31 Thread Kyle Edwards via CMake
On Fri, 2019-05-31 at 19:07 +0200, Steven Truppe wrote:
> The problem is the line:
> if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")
> cmake_print_variables(CMAKE_MATCH_0)
> 
> doesn't print me any output ...

There are two problems with the following line:

if(${_var} MATCHES "^WITH_LIB_([AZaz]+)$")

The first argument should be _var instead of ${_var}. See the if()
documentation for more information:

https://cmake.org/cmake/help/v3.14/command/if.html#variable-expansion

The second problem is your regex. I'm guessing you were trying to do:

^WITH_LIB_([A-Za-z]+)$

Notice the hyphens in the character class brackets. This will get you
every character from A to Z and from a to z. Using just [AZaz] will
only match A, Z, a, and z (none of the letters in between.)

So, if you use the following instead:

if(_var MATCHES "^WITH_LIB_([A-Za-z]+)$")
  cmake_print_variables(CMAKE_MATCH_0)

this should do what you want.

Kyle
-- 

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] Split Build and Test Pipelines

2019-05-10 Thread Kyle Edwards via CMake
On Fri, 2019-05-10 at 12:06 -0500, Dustyn Blasig wrote:
> Hi All,
> 
> I'm curious if anyone has had success allowing two testing paths to
> coexist well.
> 
> Currently, we are using CTest to run our test executables with `make
> test`. However, on our Jenkins system, the build machines have the
> whole development stack but the test machines do not. So we need a
> way to package up the tests in a way that the test machines can
> simply run some generated script to do the equivalent of what CTest
> would do.
> 
> My current thought is to generate OS specific scripts `make test`
> depends on and runs. These scripts can get installed through `make
> install` if ENABLE_TEST_INSTALL is set, and then the test machine can
> run the installed scripts. The tricky part is building up the
> hierarchy of scripts in such a way that the tester just needs to run
> "test.sh" or "test.bat" at the top-level of the install hierarchy.
> 
> Any comments and suggestions greatly appreciated!
If you at least have CMake/CTest installed on the test machines (even
if you don't have compilers, libraries, etc.), then you can create a
CMake project that doesn't build any code, but instead runs tests
against a set of external executables.
The build process for CMake itself has a mechanism to do exactly this:
if you configure CMake with -DCMake_TEST_EXTERNAL_CMAKE=path/to/bin,
then it will execute the test suite against the external CMake
executable without building any code. You could do something similar in
your own project: add an option to instead run the test suite against
an set of external excutables instead of building them.
Hope that helps!
Kyle

-- 

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] Can arguments in an command invocation end in a line comment?

2019-05-07 Thread Kyle Edwards via CMake
On Wed, 2019-05-08 at 00:52 +0300, Maris Razvan wrote:
I apologize for the spelling error in the subject of this thread.


I was told that this sentence actually states that lines inside a
(single) command argument cannot end in a line comment.
I initially thought that "Command Arguments" in this sentence means
the "section" that contains all the arguments in a command
invocation,
as the wording implies that there may be multiple lines inside the
referred "Command Arguments".
However, a bracketed or a quoted argument can span several lines, so
the sentence means that one cannot have comments in a bracketed or
quoted argument (the grammar does not allow unescaped "#" inside an
unquoted argument, so I think the sentence does not refer to this
case).


Is this correct?

This is valid:

my_command(
  ARG1 # This comment is not part of an argument
    # Neither is this
  ARG2
  )

This is also valid:

my_command(
  "ARG1
    # But this comment IS part of an argument
    "
  [==[ARG2
    # And so is this
    ]==]
  )

Hope that helps,

Kyle
-- 

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] Ubuntu CMake Repository Now Available

2019-04-09 Thread Kyle Edwards via CMake
Rebuilt for 18.04 and verified to depend on libcurl4. The new package
version is "3.14.1-0kitware1ubuntu18.04.1".
Kyle
On Tue, 2019-04-09 at 13:38 -0700, Benjamin Shadwick wrote:
> I believe it's possible to specify an "or" rule so that it would work
> with either package. It should probably require the one it's built
> against though, or at least prefer it if it works with both.
> 
> On Tue, Apr 9, 2019 at 12:32 PM Hahn, Steven E. via CMake 
> e.org> wrote:
> > Would you consider updating the Ubuntu 18.04 package to depend on
> > libcurl4?
> > 
> > Unfortunately libcurl3 conflicts with libcurl4, and I need to keep
> > the later installed for packages that depend on it. The Ubuntu-
> > provided CMake package appears to be built against libcurl4.
> > 
> > Steven
> > 
> > On 4/5/19, 3:17 PM, "CMake on behalf of Kyle Edwards via CMake" 
> > make-boun...@cmake.org on behalf of cmake@cmake.org> wrote:
> > 
> >     All,
> > 
> >     I am pleased to announce that Kitware is now offering an
> >     officially-supported set of Ubuntu packages for CMake. These
> > CMake
> >     packages can be installed with apt-get, just like other Ubuntu
> >     packages. We currently support Ubuntu 16.04 and 18.04.
> > 
> >     The following packages are available:
> > 
> >     * cmake - Contains the CMake command line executable, CTest,
> > and CPack.
> >     * cmake-curses-gui - Contains ccmake.
> >     * cmake-qt-gui - Contains cmake-gui.
> >     * cmake-doc - Contains the CMake documentation.
> > 
> >     To use these packages, follow the instructions at
> > 
> >     https://apt.kitware.com/
> > 
> >     to add our APT repository to your Ubuntu installation, and then
> > use
> >     apt-get install to install one or all of the above packages.
> > 
> >     We currently offer CMake 3.14.1, and will continue to update
> > the
> >     repository as new CMake releases are issued.
> > 
> >     Kyle
> >     -- 
> > 
> >     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.ht
> > ml
> > 
> >     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://ww
> > w.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


Re: [cmake-developers] Ubuntu CMake Repository Now Available

2019-04-08 Thread Kyle Edwards via cmake-developers
On Sat, 2019-04-06 at 10:56 +0200, Rolf Eike Beer wrote:
> Nice!
> 
> The magic spell for TravisCI is:
> 
> addons:
>   apt:
> sources:
>   - sourceline: 'deb https://apt.kitware.com/ubuntu/ xenial main'
> key_url: 'https://apt.kitware.com/keys/kitware-archive-2019.a
> sc'
> packages:
>   - cmake
> 
> Or "trusty" if you still use the default distro.
> 
> Eike

Awesome! Thanks for the tip Eike!

Please keep in mind that we don't officially support Trusty (though
that doesn't necessarily mean the binaries won't work), and we don't
have a repository named "trusty" on our server, so I don't think
putting "trusty" in the source line will work.

Also, it now occurs to me that we should have a "latest" key so that
use cases like this don't have to change the URL every year. I have
just done this, so the key URL is now:

https://apt.kitware.com/keys/kitware-archive-latest.asc

Kyle
-- 

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


[CMake] Ubuntu CMake Repository Now Available

2019-04-05 Thread Kyle Edwards via CMake
All,

I am pleased to announce that Kitware is now offering an
officially-supported set of Ubuntu packages for CMake. These CMake
packages can be installed with apt-get, just like other Ubuntu
packages. We currently support Ubuntu 16.04 and 18.04.

The following packages are available:

* cmake - Contains the CMake command line executable, CTest, and CPack.
* cmake-curses-gui - Contains ccmake.
* cmake-qt-gui - Contains cmake-gui.
* cmake-doc - Contains the CMake documentation.

To use these packages, follow the instructions at

https://apt.kitware.com/

to add our APT repository to your Ubuntu installation, and then use
apt-get install to install one or all of the above packages.

We currently offer CMake 3.14.1, and will continue to update the
repository as new CMake releases are issued.

Kyle
-- 

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] Ubuntu CMake Repository Now Available

2019-04-05 Thread Kyle Edwards via cmake-developers
All,

I am pleased to announce that Kitware is now offering an
officially-supported set of Ubuntu packages for CMake. These CMake
packages can be installed with apt-get, just like other Ubuntu
packages. We currently support Ubuntu 16.04 and 18.04.

The following packages are available:

* cmake - Contains the CMake command line executable, CTest, and CPack.
* cmake-curses-gui - Contains ccmake.
* cmake-qt-gui - Contains cmake-gui.
* cmake-doc - Contains the CMake documentation.

To use these packages, follow the instructions at

https://apt.kitware.com/

to add our APT repository to your Ubuntu installation, and then use
apt-get install to install one or all of the above packages.

We currently offer CMake 3.14.1, and will continue to update the
repository as new CMake releases are issued.

Kyle
-- 

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


Re: [CMake] Generate and install a file

2019-03-28 Thread Kyle Edwards via CMake
On Thu, 2019-03-28 at 16:38 -0400, Norton Allen wrote:
> Related to that, I noticed in another thread the mention of
> 'CMAKE_SKIP_INSTALL_ALL_DEPENDENCY'. If that were set in this case,
> how could I indicate that install depends on mygeneratedtarget? 

There is no way to do this. C/C++ targets (executables and libraries)
suffer from the same problem: if you set
CMAKE_SKIP_INSTALL_ALL_DEPENDENCY and then run "make install" without
running "make" first, the install rule will complain that it can't find
the files (such as libfoo.a.) If you set
CMAKE_SKIP_INSTALL_ALL_DEPENDENCY, you have to make sure the targets
you want to install are built before running "make install".

Kyle
-- 

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] Generate and install a file

2019-03-28 Thread Kyle Edwards via CMake
On Thu, 2019-03-28 at 16:07 -0400, Norton Allen wrote:
> Kyle,
> What you say makes sense, and I can even understand why
> add_custom_target might do that, but I cannot get this to actually
> work. Here is a minimal CMakeLists.txt. mysourcefile is just and
> empty file.
> I have these files in test/cmake, and I:
> cd test
> mkdir build-cmake
> cd build-cmake
> cmake ../cmake
> make
> and there is no sign of mygeneratedfile. I then try
> make install
> and I get:
> $ make install
> Install the project...
> -- Install configuration: ""
> CMake Error at cmake_install.cmake:31 (file):
>   file INSTALL cannot find "/home/nort/test/build-
> cmake/mygeneratedfile".
> 
> 
> make: *** [Makefile:84: install] Error 1
> Where is my mistake?
One more thing: if you want the custom target to be built by "make" or
"make all", you have to give it the ALL argument:
add_custom_target(mygeneratedtarget ALL
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile
)
Otherwise you can build the target with "make mygeneratedtarget".
Kyle-- 

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] Generate and install a file

2019-03-28 Thread Kyle Edwards via CMake
On Thu, 2019-03-28 at 15:26 -0400, Norton Allen wrote:
> On 3/28/2019 3:11 PM, Kyle Edwards wrote:
> > On Thu, 2019-03-28 at 14:58 -0400, Norton Allen wrote:
> > > because mygeneratedfile is not a 'target', and I can't make it
> > > into a target with add_custom_target() because that's talking
> > > about something else entirely (commands that will be run
> > > unconditionally, not based on dependencies)
> > What exactly do you mean by "based on dependencies"? Do you mean
> > that this file has dependencies on something else, or that
> > something else has dependencies on it?
> I mean this file depends on some source files--if the source files
> change, I want to rerun the generation step.
Using the DEPENDS argument of add_custom_command() will do this.
However, add_custom_command() on its own isn't enough to ensure that
the file is generated before installation. You need to pair
add_custom_command() with add_custom_target(). Example:
add_custom_command(
  OUTPUT mygeneratedfile
  COMMAND mytool -o mygeneratedfile
  DEPENDS mysourcefile
)
add_custom_target(mygeneratedtarget
  DEPENDS mygeneratedfile
)

This is different from:

add_custom_target(mygeneratedtarget
  COMMAND mytool -o mygeneratedfile
  BYPRODUCTS mygeneratedfile
  DEPENDS mysourcefile
)

because it will only run mytool when it needs to (when mysourcefile has
changed).

Kyle-- 

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] Generate and install a file

2019-03-28 Thread Kyle Edwards via CMake
On Thu, 2019-03-28 at 14:58 -0400, Norton Allen wrote:
> because mygeneratedfile is not a 'target', and I can't make it into a
> target with add_custom_target() because that's talking about
> something else entirely (commands that will be run unconditionally,
> not based on dependencies)
What exactly do you mean by "based on dependencies"? Do you mean that
this file has dependencies on something else, or that something else
has dependencies on it?
Kyle-- 

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] Install without building unittests

2019-03-28 Thread Kyle Edwards via CMake
You could build CMake with -DBUILD_TESTING=OFF. This will skip the unit
tests altogether.
Kyle
On Thu, 2019-03-28 at 02:24 +, Scott Bloom wrote:
> Note, Im running from inside visual studio…  I do realize for a
> makefile based system, I can run make install from inside the
> executable’s build directory
>  
> From: CMake  On Behalf Of Scott Bloom
> Sent: Wednesday, March 27, 2019 7:23 PM
> To: cmake@cmake.org
> Subject: [CMake] Install without building unittests
>  
> I asked this a couple of years ago, and the answer was “no”…
> 
> If you run tests, it doesn’t automatically build tests…  So why does
> an install?
>  
> I would never release something into the wild with out running the
> tests…
>  
> But, for developer builds, were we need to install all the packages
> in order to run the applications, sometimes I just want to test the
> GUI which requires an install of the core application into the
> correct location, without building the 1500+ (yes 1500) unittests,
> which can take 15-20 minutes to build on their own…
>  
> Is there anyway to break the dependency??
> 
> Scott
> -- 
> 
> 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/op
> ensource/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


Re: [CMake] CMake Project Generation Speedup

2019-03-20 Thread Kyle Edwards via CMake
On Wed, 2019-03-20 at 16:57 -0400, J. Caleb Wherry wrote:
> I was also surprised when "cmake --trace" gave 0 information related
> to the generate step. I assume this is expected behavior?
The purpose of --trace is to debug CMake scripts. No scripts get run
during the generate step, so yes, this is expected.
Kyle-- 

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] Question about find_packages.

2019-03-15 Thread Kyle Edwards via CMake
On Fri, 2019-03-15 at 17:03 +0100, workbe...@gmx.at wrote:
> Hi everyone,
> 
> i try to use find_packages for clang, i'm on debian and have
> installed
> libclang-4.0-dev package, now i've the files in
> /usr/lib/llvm4-0/lib/libclang-4.0.so and the include in
> /usr/lib/llvm-4.0/include/clang - how can i make find_package find
> those ??

LLVM contains package config files which give you all of this
information. Use find_package() as normal:

find_package(LLVM)

And then invoke CMake with:

$ cmake . -DLLVM_DIR=/usr/lib/llvm-4.0/cmake

Kyle
-- 

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] [ANNOUNCE] CMake 3.14.0 available for download

2019-03-14 Thread Kyle Edwards via CMake
On Thu, 2019-03-14 at 14:37 -0400, Sean McBride wrote:
> On Thu, 14 Mar 2019 11:58:16 -0400, Robert Maynard via CMake said:
> 
> > 
> > I am happy to announce that CMake 3.14.0 is now available for
> > download at:
> >  https://cmake.org/download/
> Pi version on Pi Day.  Nicely done!  :)  Couldn't you have waited
> until 3:14 to release it?  :)

We thought about releasing it at 1:59, but we didn't want to wait until
the afternoon :)

Kyle
-- 

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] cpack_add_component

2019-03-11 Thread Kyle Edwards via CMake
On Mon, 2019-03-11 at 17:59 +0100, Micha Renner wrote:
> In CPack I can add a component with cpack_add_component and describe
> the component with the additional arguments of the macro.
> I can also describe the component if I use the varibales of type
> CPACK_COMPONENT__XXX (e.g.
> CPACK_COMPONENT__HIDDEN).
> So which one is the right way? Or doesn't matter which way I use.

The cpack_add_component() macro is merely a convenience function to set
the CPACK_COMPONENT__XXX variables. You can use either one. I
typically use the macros.

Kyle
-- 

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] Remove a custom command added with add_custom_command( POST_BUILD ...)

2019-03-05 Thread Kyle Edwards via CMake
On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote:
> Hello,
> 
> I have been searching for a way to remove a custom command
> (POST_BUILD
> event) from a target in CMake but, so far, I've found nothing.
> 
> I tried to add another custom command to override the first one but
> it seems
> to append a second command. 
> I tough that could work because of the first signature of
> add_custom_command() that can take an optional argument named APPEND.
> https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen
> erating-files
> Then, I looked for a target property that contains the POST_BUILD
> custom
> command (to erase it) but, again, I found nothing related (I listed
> every
> property using the "cmake --help-property-list" command).
> 
> 
> The context is that I configure a project using a "CMake SDK" from a
> third
> party library (custom functions that create and configure a shared
> library
> target basically).
> Until recently, I used to create those target by myself using
> standard CMake
> command.
> But now I switched to the "SDK" because it does a lot of specific
> thing
> depending on the platform (and between the current version of the SDK
> and
> all the legacy version) and I don't want to rewrite everything.
> 
> Specifically, this SDK add a custom command as a POST_BUILD event to
> run a
> tool that perform a signature on the produced library. As it is a
> proprietary tool that requires a valid licence to work, I want to
> remove
> that command in order to have a successful build even if i don't
> currently
> have a licence on my machine.
> 
> So ... is there some way to remove a custom command in CMake ? (or
> ignore
> failed command maybe)

CMake doesn't have a way to remove a custom command from a target. Your
best bet would be to either:

1) Fork the SDK for your project to remove the proprietary tool, or
2) Submit a patch upstream to add an option to disable the proprietary
tool.

Kyle
-- 

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] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop.

2019-03-01 Thread Kyle Edwards via CMake
On Fri, 2019-03-01 at 17:49 +0800, Yu, Mingli wrote:
> Hi Expert,
> 
> I encounter build issue when compile mariadb from 
> https://downloads.mariadb.org/mariadb/10.3.13/
> 
> 
> make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 
> 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'.  Stop.
> 
> And the content of libmysqld/CMakeLists.txt as attached, any ideas?

I don't see anything in this file for actually *generating*
sql_yacc.cc. This should be generated by using add_custom_command() to
call yacc. Is that happening in another file?

Kyle
-- 

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] Question about set

2019-02-18 Thread Kyle Edwards via CMake
On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote:
> Hey,
> 
> I would introduce a list with the allowed values and introduce a
> macro 
> "checked_set", which tests the setting or aborts.
> 
> Regards,
> Andreas"
> 
> Am 18.02.19 um 15:06 schrieb workbe...@gmx.at:
> > 
> > Hi everyone,
> > 
> > i've looked the web but found no result. I need a string variable
> > that 
> > allows only certain values, like bool variables only allow
> > true/false 
> > my string should be either "A" or "B" ...

Is this a cache variable or a regular variable? Cache variables have
this enum-like support in the form of the STRINGS property. Example:

set(MYSTRING "A" CACHE STRING "Documentation for the variable")
set_property(CACHE MYSTRING PROPERTY STRINGS "A;B")

If you need to do this with an ordinary variable, consider using
variable_watch().

Kyle
-- 

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] Fwd: Re: Question about CMAKE_MODULE_PATH

2019-02-18 Thread Kyle Edwards via CMake
On Mon, 2019-02-18 at 17:04 +0100, workbe...@gmx.at wrote:
> 
> 
> 
>  Forwarded Message 
> Subject:  Re: [CMake] Question about CMAKE_MODULE_PATH
> Date: Mon, 18 Feb 2019 16:58:26 +0100
> From: workbe...@gmx.at 
> To:   Kyle Edwards 
> 
> here is my code:
> 
> 
> set(MODULE_PATH "compile/tools/cmake/modules")
Try this instead:
set(MODULE_PATH "${CMAKE_SOURCE_DIR}/compile/tools/cmake/modules")
Kyle

-- 

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] Question about CMAKE_MODULE_PATH

2019-02-18 Thread Kyle Edwards via CMake
On Mon, 2019-02-18 at 16:50 +0100, workbe...@gmx.at wrote:
> Doesn't the content of CMAKE_MODULE_PATH should also include the path
> to 
> the default modules ??

The default modules are automatically checked by CMake, independently
of the contents of CMAKE_MODULE_PATH. They should not normally be
present in CMAKE_MODULE_PATH.

> > i try to load custom modules. i use
> > 
> > 
> > list(append CMAKE_MODULE_PATH "/mypathtomdoules")

The "append" argument should be uppercase:

list(APPEND CMAKE_MODULE_PATH "/mypathtomodules")

Did you receive any warnings about an invalid argument to list()?

Kyle
-- 

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] undefined reference to `_exit'

2019-02-01 Thread Kyle Edwards via CMake
Hex,
Can you see what else is in /opt/arm-none-eabi/lib/thumb/v7-
ar/fpv3/hard (the same directory as libc.a)? There might be another
system library that contains the _exit() implementation that isn't
being linked due to your use of the -nostartfiles flag.
Kyle
On Fri, 2019-02-01 at 22:15 +, hex wrote:
> hello, 
> I am trying to include a static library that contains the startup
> code for ARM processor to my  CMake project for cross compilation. 
> I included the linker script and added it to the executable. Flags
> and include files are properly set in the CMake build output. The
> path to the library is also correctly seen. 
> The linker fails on the startup code:
> 
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/src/main.c.obj
> [100%] Linking CXX executable testApp
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-exit.o): In function `exit':
> exit.c:(.text.exit+0x1c): undefined reference to `_exit'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-fini.o): In function `__libc_fini_array':
> fini.c:(.text.__libc_fini_array+0x2c): undefined reference to `_fini'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-init.o): In function `__libc_init_array':
> init.c:(.text.__libc_init_array+0x38): undefined reference to `_init'
> collect2: error: ld returned 1 exit status
> 
> 
> Here is my CMakeLists file:
> 
> cmake_minimum_required(VERSION 3.5.1)
> project (hello-world)
> 
> set(SOURCE_FILES src/main.c)
> 
> set (LINKER_SCRIPT linker_script.ld)
> 
> add_executable(${TARGET_NAME} ${SOURCE_FILES})
> 
> set_target_properties( ${TARGET_NAME} PROPERTIES LINK_DEPENDS
> ${LINKER_SCRIPT})
> 
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-build-
> id=none -Wl,-T ${LINKER_SCRIPT} " CACHE STRING "" FORCE )
> 
> set(COMMON_FLAGS "${COMMON_FLAGS} -march=armv7-a")
> set(COMMON_FLAGS "${COMMON_FLAGS} -mfpu=vfpv3")
> set(COMMON_FLAGS "${COMMON_FLAGS} -mfloat-abi=hard")
> set(COMMON_FLAGS "${COMMON_FLAGS} -Wall")
> set(COMMON_FLAGS "${COMMON_FLAGS} -O0")
> set(COMMON_FLAGS "${COMMON_FLAGS} -nostartfiles")
> set(COMMON_FLAGS "${COMMON_FLAGS} -fmessage-length=0")
> set(COMMON_FLAGS "${COMMON_FLAGS} -fno-exceptions")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_FLAGS}")
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_FLAGS}")
> 
> include_directories( inc )
> 
> find_library(LIB_C NAMES libc PATHS "lib" )
> 
> target_link_libraries(${TARGET_NAME} ${LIB_C})
> 
> 
> How can I solve this problem? The only dependency here is the library
> itself...
> 
> Thank you in advance for any response. 
> -- 
> 
> 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/op
> ensource/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


Re: [CMake] FindOpenSSL.cmake

2019-02-01 Thread Kyle Edwards via CMake
Andrew,
FindOpenSSL provides an "OPENSSL_ROOT_DIR" variable which allows you to
specify the root directory of your installation (assuming a traditional
layout within that directory.) Hopefully this will do what you need.
Good luck!
Kyle
On Fri, 2019-02-01 at 16:18 -0500, Andrew Bell wrote:
> I have a system-provided SSL and I have a newer one that I have
> installed via a packaging system.  In my build system I have:
> find_package(OPENSSL 1.1) .  This properly finds the version 1.1
> header files for openSSL, but it finds the incompatible system
> libraries, which are older than version 1.1.  A look at
> FindOpenSSL.cmake makes it seem as if the version is used when
> finding the header files, but not the libraries.  Other than
> overriding cache entries, is there a way to fix the
> FindOpenSSL.cmake that would solve the problem?  Other suggestions?
> 
> -- 
> 
> 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/op
> ensource/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


Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Kyle Edwards via cmake-developers
On Fri, 2019-01-25 at 14:06 -0800, Venedict Tchistopolskii wrote:
> Could you clarify on saving the build-directory section?
> 
> I'm not sure how it knows which cache or build directory to load. In
> my setup here the issue I noted applies even if build directory is
> generated on both projects/etc.
> 
> VT
As a convenience, cmake-gui uses a QSettings object to store the last
few build directories that it configured. These directories are
populated in the build directory dropdown menu.
The source directories are not stored in QSettings at all, but instead
extracted from the build directories. If the build directory hasn't
been configured, then CMake has no way of knowing what source directory
to pick.
Kyle
> 
-- 

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


Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Kyle Edwards via cmake-developers
On Fri, 2019-01-25 at 13:23 -0800, Venedict Tchistopolskii wrote:
> Get 2 CMake projects.
> 
> Get CMake GUI to 'configure' one of them. Close/re-open and it will
> automatically point to this configured project source and build
> locations, regardless of what build/version/cmake-gui.exe you use. 
> 
> Run a different cmake-gui.exe through the CLI, passing in source and
> build locations. It will be properly load these instead of the 'last
> configured project' now.
> 
> Now close it, without configuring, and re-open it normally without
> CLI overrides. Now it'll load the original project as if you've never
> set it to a different source/build location.
> 
> tl;dr CMake loads the last-configured source/bin directory by
> default. If you don't configure (or pass override through CLI) it
> will keep loading the same project.
Ah, I see what you mean.
Saving the build path is easy: just add the command-line path to the
cache of build directories on startup as well as at configure time.
Saving the source path is more difficult. The GUI gets the source
directory by scanning the files in the build directory. If the build
directory hasn't been generated yet, then the GUI will have no idea
where to find the source directory, unless we start caching source
directories as well.
I think, as you noted, you're better off just triggering "Configure"
before closing the dialog.
Kyle
> 
-- 

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


Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Kyle Edwards via cmake-developers
On Fri, 2019-01-25 at 12:55 -0800, Venedict Tchistopolskii wrote:
> Cherry picked and tested. Works great, thank you!
Great, glad to hear it!
> Now, if only the source/build path would stick around, without requiring 
> config to be triggered. :P
Can you clarify what you mean by this?
Kyle
> 
-- 

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


Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Kyle Edwards via cmake-developers
Venedict,
Currently, cmake-gui only lets you specify a build or source directory,
not both.
I've opened https://gitlab.kitware.com/cmake/cmake/merge_requests/2863 
to add explicit -S and -B options to cmake-gui, which will allow you to
specify both.
Kyle
On Fri, 2019-01-25 at 08:10 -0800, Venedict Tchistopolskii wrote:
> Actually that doesn't work.
> cmake-gui.exe "D:/GitHub/SOURCE"
> "D:/GitHub/SOURCE/solutions_cmake/win64"
> 
> Ignores both options, but
> cmake-gui.exe "D:/GitHub/SOURCE"
> 
> Uses current directory as noted. Why? Syntax wrong or something?
> 
> VT
> 
> 
> On Fri, Jan 25, 2019 at 6:52 AM Kyle Edwards 
> m> wrote:
> > On Fri, 2019-01-25 at 09:18 +0100, Gößwein Matthias / eeas gmbh
> > wrote:
> > > However, the manual does not describe this behavior, maybe it
> > should
> > > be
> > > mentioned there.
> > > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html)
> > 
> > Even better, perhaps we should add explicit -B and -S options the
> > way
> > cmake and ccmake already do.
> > 
> > Kyle
> > -- 

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


Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI

2019-01-25 Thread Kyle Edwards via cmake-developers
On Fri, 2019-01-25 at 09:18 +0100, Gößwein Matthias / eeas gmbh wrote:
> However, the manual does not describe this behavior, maybe it should
> be
> mentioned there.
> (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html)

Even better, perhaps we should add explicit -B and -S options the way
cmake and ccmake already do.

Kyle
-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
On Thu, 2019-01-24 at 12:31 -0800, Venedict Tchistopolskii wrote:
> Nevermind, fixed the cmake-gui.
Ah OK, then disregard my response.
> Would be nice to know how to triger the proper install/release config from 
> VStudio, atm I do this:
> cmake . --target install --config Release
This looks correct for doing it on the command line.
The VStudio solution should have an "INSTALL" project which does what
you want.
Kyle
> 
-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
On Thu, 2019-01-24 at 12:25 -0800, Venedict Tchistopolskii wrote:
> The install command auto-installs release right?
> How do I trigger this 'install' from VStudio?
> Is building in VStudio enough before install?
>   e.g. generate solution -> build in VStudio -> run install
> command in CLI?
Yes, this will work.
> Just not sure on the proper flow because I use VStudio to debug/modify/test 
> CMake.
Usually debugging etc. is done on the .exe inside the build tree,
rather than the install tree.
> Additionally with this setup cmake-gui.exe can't find Qt5widgets etc. no 
> matter what I do.
You mean at build-time, or at runtime?
> It finds it if I use the .exe built by VStudio.
Does the one in VStudio have all the Qt DLLs beside it in the
directory?
Kyle
> 
-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote:
> cmake --build . --target install
> windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe

Oops - this should obviously be
C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe.
Kyle-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
On Thu, 2019-01-24 at 09:27 -0800, Venedict Tchistopolskii wrote:
> Er, lemme clarify.
> 
> Can cmake-gui.exe be built along with cmake if using the install path
> setting? I currently use windeployqt to handle gui dependencies.
Yes, like I mentioned, just build with BUILD_QtDialog=ON. You can then
run windeployqt after running cmake --build . --target install:
cmake --build . --target install
windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe
Kyle
> 
-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
On Thu, 2019-01-24 at 09:23 -0800, Venedict Tchistopolskii wrote:
> I was building it via VStudio and generating the solution via CMake,
> is that wrong?
Nope! You're building it just fine. The only problem is in the
installation - you were installing cmake.exe without all of the
external files it needs. Running cmake --build . --target install will
take care of this for you.
> I need cmake-gui.exe to be built too, would that work with this install path 
> setting?
Yes. You just need to make sure BUILD_QtDialog is turned ON:
cmake C:/Path/To/CMake/Source
-DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install
-DBUILD_QtDialog=ON
Keep in mind that you will need a Qt installation to build cmake-gui.
Kyle
> 
-- 

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


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
I forgot to mention - building it this way doesn't require the use of a
toolchain file - it was in response to this:
> Trying to do so because building CMake without toolchain gives me the
below; After I move cmake.exe to another directory:

If you build it as I laid out below, you won't need a toolchain file.
Hope this helps!
Kyle
On Thu, 2019-01-24 at 12:09 -0500, Kyle Edwards wrote:
> Venedict,
> 
> To relocate cmake.exe, it's not sufficient to just copy the
> executable - you have to install all of the modules along with it.
> You do this by running the "install" target.
> 
> Given a path to where you want to put CMake, you would build it like
> this:
> 
> cmake C:/Path/To/CMake/Source
> -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install
> cmake --build .
> cmake --build . --target install
> 
> This will install cmake.exe along with all of its dependencies.
> 
> Kyle
> 
> On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote:
> > Hey there!
> > 
> > Current toolchain file for compiling CMake using CMake (on
> > WIndows):
> > SET(CMAKE_SYSTEM_NAME Windows)
> > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
> > 
> > Unfortunately this konks out with:
> > CMake Error: The following variables are used in this project, but
> > they are set to NOTFOUND.
> > Please set them or make sure they are set and tested correctly in
> > the CMake files:
> > LIBMD_LIBRARY
> >     linked by target "cmTC_356fd" in directory
> > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp
> > 
> > Trying to do so because building CMake without toolchain gives me
> > the below; After I move cmake.exe to another directory:
> > CMake Error: Could not find CMAKE_ROOT !!!
> > CMake has most likely not been installed correctly.
> > Modules directory not found in
> > 
> > Usage
> > 
> >   cmake [options] 
> >   cmake [options] 
> >   cmake [options] -S  -B 
> > 
> > Specify a source directory to (re-)generate a build system for it
> > in the
> > current working directory.  Specify an existing build directory to
> > re-generate its build system.
> > 
> > Run 'cmake --help' for more information.
> > 
> > Please advise!!
> > 
> > VT
> > 
> > 
> > -- 
> > 
> > Powered by www.kitware.com
> > 
> > Please keep messages on-topic and check the CMake FAQ at: http://ww
> > w.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-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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Compiling static/stand-alone CMake.exe

2019-01-24 Thread Kyle Edwards via cmake-developers
Venedict,
To relocate cmake.exe, it's not sufficient to just copy the executable
- you have to install all of the modules along with it. You do this by
running the "install" target.
Given a path to where you want to put CMake, you would build it like
this:
cmake C:/Path/To/CMake/Source
-DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install
cmake --build .
cmake --build . --target install
This will install cmake.exe along with all of its dependencies.
Kyle
On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote:
> Hey there!
> 
> Current toolchain file for compiling CMake using CMake (on WIndows):
> SET(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
> 
> Unfortunately this konks out with:
> CMake Error: The following variables are used in this project, but
> they are set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the
> CMake files:
> LIBMD_LIBRARY
>     linked by target "cmTC_356fd" in directory
> D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp
> 
> Trying to do so because building CMake without toolchain gives me the
> below; After I move cmake.exe to another directory:
> CMake Error: Could not find CMAKE_ROOT !!!
> CMake has most likely not been installed correctly.
> Modules directory not found in
> 
> Usage
> 
>   cmake [options] 
>   cmake [options] 
>   cmake [options] -S  -B 
> 
> Specify a source directory to (re-)generate a build system for it in
> the
> current working directory.  Specify an existing build directory to
> re-generate its build system.
> 
> Run 'cmake --help' for more information.
> 
> Please advise!!
> 
> VT
> 
> 
> -- 
> 
> 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/op
> ensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [CMake] CPack and WIX: Preselected components

2019-01-17 Thread Kyle Edwards via CMake
Micha,

Unfortunately, the WiX generator does not currently support component
installation, which is what's needed to make the INSTALL_TYPES argument
work.

We would welcome a merge request which adds this support.

Kyle

On Thu, 2019-01-17 at 19:28 +0100, Micha Renner wrote:
> With the NSIS generator I can create a dialog with a drop_down list
> with two elements default and developer. Default is selected by
> default
> when the dialog starts, so the default parts of the package are
> installed. Selecting developer the devlop parts are installed and the
> default files not. 
> 
> How can I do the same with the WiX generator?
> 
> With code below the WiX generator installs the complete package. 
> What I want is that the user can selected the develop part if he
> wants
> it.
> 
> 
> ___
> Example as it works with NSIS. There is nothing specific for NSIS.
> 
> ADD_LIBRARY(mylib mylib.c)
> 
> ADD_EXECUTABLE(myapp myapp.c mylib.h)
> TARGET_LINK_LIBRARIES(myapp mylib)
> 
> INSTALL(TARGETS mylib ARCHIVE DESTINATION lib COMPONENT libraries)
> INSTALL(TARGETS myapp RUNTIME DESTINATION bin COMPONENT applications)
> INSTALL(FILES mylib.h DESTINATION include COMPONENT headers)
> INSTALL(FILES free.txt DESTINATION doc COMPONENT dokumentation)
> 
> # WIX specific
> SET(CPACK_WIX_UPGRADE_GUID 939B61C9-8E66-4876-A425-F7CDD7E6A6B2)
> SET(CPACK_GENERATOR WIX)
> 
> INCLUDE(CPackComponent)
> 
> cpack_add_install_type(Default DISPLAY_NAME Default)
> cpack_add_install_type(Developer)
> 
> cpack_add_component(applications DISPLAY_NAME "App" DESCRIPTION
> "Application only"
> GROUP "Runtime" INSTALL_TYPES Default)
> 
> cpack_add_component(dokumentation DISPLAY_NAME "Doc" DESCRIPTION "Doc
> for the app"
> GROUP "Runtime" INSTALL_TYPES Default)
>   
> cpack_add_component(libraries DISPLAY_NAME "lib" DESCRIPTION "For
> devloper only"
>   GROUP "Development" INSTALL_TYPES Developer)
> 
> cpack_add_component(headers DISPLAY_NAME "C++ Headers" DESCRIPTION
> "C/C++ header files for use with MyLib"
> DEPENDS libraries INSTALL_TYPES Developer GROUP "Development")
> 
> cpack_add_component_group(Runtime)
> cpack_add_component_group(Development DESCRIPTION "All you need for
> development")
> 
> SET(CPACK_COMPONENT_GROUP_DEVELOPMENT_PARENT_GROUP "Runtime")
> 
> INCLUDE(CPack)
> 
-- 

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 QtTest integration

2019-01-15 Thread Kyle Edwards via CMake
Hello all,

I recently wrote a set of scripts to integrate QtTest into CMake,
similar to the work that Matthew Woehlke did with Google Test a while
back. The script that I wrote runs the test executable in the post-
build stage, records the list of tests in the executable, and generates
a CTest script to run them. It uses the same TEST_INCLUDE_FILES
property that the Google Test test discovery functionality uses.

You can check out the source code here:

https://github.com/Kitware/seal-tk/blob/master/src/test/CMakeLists.txt
https://github.com/Kitware/seal-tk/blob/master/cmake/QtTestDiscoverTest
s.cmake

Kyle
-- 

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] Help with non-standard use of CMake

2019-01-02 Thread Kyle Edwards via CMake
On Wed, 2019-01-02 at 12:01 -0500, Donald MacQueen [|] wrote:
> I looked at the example of Using ctest and cdash without cmake 
> (https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTE
> ST-and-CDASH-without-CMAKE#steercmake) 
> and I think I will try to go in that direction.

Donald,

I just looked at that page, and it looks like it was written a very
long time ago, before cmake_host_system_information() and
execute_process() were created. The exec_program() command has been
deprecated for years. I'm going to work on updating it a little bit
right now.

Kyle
-- 

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] Help with non-standard use of CMake

2019-01-02 Thread Kyle Edwards via CMake
On Tue, 2019-01-01 at 16:55 -0500, Donald MacQueen [|] wrote:
> No. CMakelists.txt does nothing but download the correct installer
> (32 or 64 bit) from our server, set a bunch of variables, and then
> run CTest.  I invoke the InstallShield installer from a command line
> in a CTest.
> There is no project, no make, no compile, no build. Just set a bunch
> of variables and run CTest.
> I think from what Kyle said I need to migrate(?) this to a script
> that can be called from CTest directly, e.g., ctest -D Experimental
> -S cdash.txt.
> Thanks for the reply.

If CMakeLists.txt is only downloading and running an installer, then
perhaps it would be best to move this step into your CTest dashboard
script as you suggested. Your CMakeLists.txt is generating the
CTestTestfile.cmake file for you, but you can also write this file
yourself with a series of add_test() calls, which would enable you to
completely get rid of CMakeLists.txt.

If you're not comfortable doing this, you can also just do project(foo
LANGUAGES NONE) in your CMakeLists.txt as has already been suggested.

FWIW, the usual convention for CMake scripts is for anything other than
CMakeLists.txt to have a .cmake extension (though this isn't enforced,
it's just a convention.) And the -D argument to CTest isn't necessary
when running a dashboard script. So your CTest invocation would look
like this:

ctest -S dashboard.cmake

You can also have this script run ctest_configure(), which will run
CMake for you (if you decide not to migrate from CMakeLists.txt) so you
don't have to do it in the batch file.

Good luck, and let us know if you have any more questions!

Kyle
-- 

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] Help with non-standard use of CMake

2018-12-31 Thread Kyle Edwards via CMake
On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote:
> First, CMake is quite impressive. Nice job.
> 
> I am using it in a non-standard way where I set a bunch of variables
> and 
> then go straight to CTest thatI installs our software and then runs 
> several hundred tests on it. The batch file looks like this:
> 
> rmdir /s/q build
> mkdir build
> cd build
> cmake -Dx64=%x64% -Doption:STRING="%opt%" ..
> ctest -D Experimental -S
> 
> I do not make or build or compile.
> 
> I recently hooked this up to a CDash server which is very handy. I
> want 
> to get the results that are sent to CDash, currently from Windows
> only, 
> to be all green.
> 
> Under Build I have one error: Build log line 2. The system cannot
> find 
> the file specified. CMake Error: Generator: execution of make
> failed. 
> Make command was: "nmake" "/nologo" "-i"

You could try one of several things:

1) Running with a different generator, such as one of the Visual Studio
   generators or the Ninja generator, or
2) Installing NMake.

However, I am a little curious about what you're doing in your use
case. You say you're not building anything. Does your sofware exist in
the form of scripts (Python, Perl, etc.), or are you downloading pre-
built binaries from somewhere?

> Under Build I have one warning: Build log line 1. *** WARNING non-
> zero 
> return value in ctest from: C:\Program Files\CMake\bin\cmake.exe
> 
> Is there a way to suppress the execution of these steps or their
> error 
> messages?

Without knowing more details about what you're doing, it's possible
that dashboard scripts might be more suited for your use case... though
I see you have a -S argument at the end of your ctest invocation but no
script after it... what's the purpose of this?

See https://cmake.org/cmake/help/v3.13/manual/ctest.1.html#dashboard-cl
ient-via-ctest-script for details on dashboard scripts.

Kyle
-- 

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] Accessing ${SITE} in CTestConfig.cmake

2018-12-31 Thread Kyle Edwards via CMake
On Mon, 2018-12-31 at 13:50 -0500, Donald MacQueen [|] wrote:
> Thanks very much Kyle. I guess I am not real clear about when vars
> should be used as var versus ${var}.

Generally speaking, you use var when setting a variable, and ${var}
when reading its value. It's a lot like how shell variables are used in
bash:

foo=bar
echo $foo

if() and while() break this convention because they were written very
early in CMake's history, before there was a concept of variable
expansion.

However, because of CMP0054, you can put ${var} in quotes:

if("${foo}" STREQUAL "bar")

and it will have the same effect as:

if(foo STREQUAL "bar")

See https://cmake.org/cmake/help/latest/policy/CMP0054.html for
details.

Kyle
-- 

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-developers] Referencing all sources in compile command

2018-12-31 Thread Kyle Edwards via cmake-developers
On Sun, 2018-12-30 at 13:09 -0800, Saleem Abdulrasool wrote:
> Hi,
> 
> I was looking at supporting Swift as a language in CMake.  I know
> that CMake has some preliminary support that assumes that you are
> building on macOS with Xcode.  I am trying to support building swift
> libraries and executables on Linux and Windows.
> 
> There is some preliminary work on this that I have put up on GitHub
> [1].  One place that I am hitting a roadblock in is the need to
> reference all the target sources in the compile rule for a single
> object.  AFAICT, there is no placeholder that will expand to the
> target sources.  Would it be acceptable to add a ``
> place holder?  Or is there another approach that would be better?
> 
> Thanks.
> 
> [1] https://github.com/compnerd/cmake-swift
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> -- 
> 
> 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/op
> ensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
Saleem,
Not sure if this will help, but have you taken a look at the
$ generator expression?
https://cmake.org/cmake/help/v3.13/manual/cmake-generator-
expressions.7.html#output-expressions
Kyle-- 

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


Re: [CMake] Accessing ${SITE} in CTestConfig.cmake

2018-12-31 Thread Kyle Edwards via CMake
On Sat, 2018-12-29 at 09:01 -0500, Donald MacQueen [|] wrote:
> My machine shows up as M6800 under Site in my remote dashboard.
> 
> I want to use my local dashboard, so I did this in 
> CTestConfigCTestConfig.cmake:
> 
> IF (${SITE} STREQUAL "M6800")
>  set(CTEST_DROP_SITE "192.168.49.128") # <---
> -- 
> local dashboard
> ELSE()
>  set(CTEST_DROP_SITE "192.168.10.150")
> ENDIF()
> 
> I also tried IF (${CTEST_SITE} STREQUAL "M6800") with no luck.
> 
> Any ideas?
> 
> Thanks.
> 
> -- 
> Donald [|]
> A bad day in [] is better than a good day in {}.
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 

Donald,

Try this instead:

if(CTEST_SITE STREQUAL "M6800")
# ...

See the documentation for the if() command to understand how to use it:

https://cmake.org/cmake/help/latest/command/if.html

Kyle
-- 

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-developers] Idea for Multi-Toolchain Support

2018-12-24 Thread Kyle Edwards via cmake-developers
On Sat, 2018-12-22 at 16:57 +0100, Torsten Robitzki wrote:
> What I’m still missing is support to define dependencies between
> different targets (build by different toolchains), so that I can
> describe that I require a tool that is build with the HostToolChain,
> to generate a file that is required by the part of the build, that is
> using the CrossToolChain. And, of cause, if the source of that tool
> changes, that tool have to be rebuild and the generated file from the
> CrossToolChain part of the build have to be rebuild.

What about add_dependencies()? Is that sufficient, or is there
something more that you need?

Kyle
-- 

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


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-19 Thread Kyle Edwards via cmake-developers
On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote:
> I have thought about it which is why I asked.  The original
> assumption of one toolchain per CMake project is being extended. So
> why not think of extending the build type.  Sure it's simpler to
> ignore the build type. However, it doesn't make sense to me to build
> and run a host tool in debug mode when it could be running faster if
> built in release mode.  This is independent of whatever I'm doing
> with cross-compiler targets. You're already updating the generator to
> pick and choose the proper flags just on the tool chain type and it
> already picks the correct flags based on the configuration type.  But
> instead of the generator looking at the global build type it looks at
> the target build type. The target build type could default to the
> global build type and be overridden via a property.
> 
> Multi config generators would be problematic if they don't have a
> Configuration Manager that allows for setting different projects with
> different configurations (like Visual Studio) but is that reason
> enough to exclude the idea for single configuration generators?
I suppose we could consider the idea of supporting this separation for
single-config generators, but I can't think of a good way to make it
work for multi-config generators.
> If this can already be simply done why is anyone asking to use multiple 
> toolchains in a single project?  You just use an ExternalProject with each 
> toolchain file and you're done, or is this a shortcut method instead of using 
> ExternalProject to build the host tool?
You can use ExternalProject, but it's a bit like using a chainsaw when
all you need is a scalpel. Multi-toolchain would make it easy to keep
host tools and target code in the same project in the *simple* case
(like the Linux kernel example I gave in a previous email.) If you want
to do something more complicated then ExternalProject would be your
best bet.
Kyle-- 

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


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-18 Thread Kyle Edwards via cmake-developers
On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
> So it would be something like project( [TOOLCHAIN
>  [LANGUAGES] [...]) where TOOLCHAIN
> and its supported languages can be repeated for each tool chain. i.e
> project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross
> LANGUAGES c)
I think this sounds about right.
> But isn't this all (or mostly) cached so you don't have to redo all this when 
> regenerating build files. I guess it would be CMAKE___* ?
Good point about caching, I did not think of that. Perhaps we need some
separate caching mechanism for toolchain properties - or perhaps the
properties could be loaded from undocumented cache variables defined
only for CMake's internal use.
> What about conflicting build types when building a host tool target vs the 
> cross compiler target?
> For instance the host tool may (should?) be built as a release project 
> (default optimization levels) but the cross compiler project could be built 
> as a debug project (so you can debug it with no optimizations)?
> I guess it would then be CMAKE__BUILD_TYPE and then targets using that 
> toolchain would be built with that build type.
I think that both host and cross targets would be built with the same
build type. If you're using a multi-config generator like VS or Xcode,
how do you specify which combination of configs you want? It's simpler
if every target is built as the same type, whether it's host or cross.
Think about it - the current system already expects that every target
in the project is built as the same build type. There's no way to
specify "foo is built as debug, bar is built as release." Why would
this assumption change just because we add a multi-toolchain mechanic?
> On the other hand this doesn't really help anyone working with mixed build 
> systems.  What you can't do in a straight forward manner is host tool 
> development with Visual Studio or Eclipse, execute it and use it's results 
> with a cross compiler (that uses Ninja or Makefiles) targeting an embedded 
> system.
Every target would be built by the same generator regardless of whether
it's a host or cross target. So if you select the VS generator, both
the host tools and the embedded software would be built in VS (if this
is possible.) Likewise for Ninja and Make.
> In this case I think that what you want is to easily control multiple
> projects using different build systems, the inter-dependencies, and
> easily specify that external project A produces a file for external
> project B.  Ideally you would be in the root of the build folder and
> type 'cmake --build .' and have it take care of everything with
> minimal extraneous build tool executions or sometimes even invoking
> the build tool in parallel for external projects that don't depend on
> each other.
> 

If you want to build different parts of the software with different
generators (build systems) then you're better off using a superbuild
with ExternalProject. The intent of this proposal is to allow users to
build both host tools and cross-compiled software in the same build
tree with the same generator.
As an example of a real-world project, I would like to emulate the
Linux kernel's separation of host and cross compiler. The vast majority
of files in the kernel source tree are built with a single cross
compiler, while a very small set of host tools are built with the host
compiler. Both the host tools and the kernel itself are built using the
same Makefile, and there's no ExternalProject-like separation between
them. The kernel's buildsystem only supports Makefiles and can't
generate Ninja, VS, etc., but if it did, then both the host tools and
the kernel would be built with the same Ninja files/VS solution. I
don't remember whether it supports building the host tools and kernel
as separate types (debug vs release), but for sake of simplicity, I'd
rather not try to support that, especially in multi-config generators.
Kyle-- 

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


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-18 Thread Kyle Edwards via cmake-developers
On Tue, 2018-12-18 at 14:10 -0500, frodak17 wrote:
> How does this work with multiple languages and the project() command
> and enable_language() commands?
Both project() and enable_language() could be extended with an optional
TOOLCHAIN argument.
> For instance you want to use the host c++ compiler and a toolchain
> specified compiler for c and c++.
> When project() enables the c++ compiler it runs through a bunch of scripts to 
> find and test the compiler also setting several CMAKE__* variables to use 
> that compiler.  These variables also happen to be the default compile options 
> for the build types when using that compiler.
The point of this idea is to get rid of the old variable-based system
and have everything instead be a property of a toolchain. So the
scripts would set properties of the default toolchain instead of
setting variables.
> Then the same thing happens with the tool-chain specified compiler
> for these languages how do you track that the variables are different
> for these two toolchains?
> Are these variables now project scoped and for any given project it
> is limited to one toolchain per language per project?
> 

See above.
Kyle-- 

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


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-18 Thread Kyle Edwards via cmake-developers
On Tue, 2018-12-18 at 06:14 -0500, frodak17 wrote:
> What first cross my mind with '"utilities" needed for build' is when
> you have to build the cross-compiler in the first place before you
> build anything for the target.
> If so how do you handle verification of the tool-chain can build a
> working executable or library?
> Normally that is done at the time before project files are generated
> but it has to either be skipped or delayed because the toolchain
> doesn't even exist because it has to be built first by the host
> tools. For tool-chains that already exist on the host machine then
> add_toolchain() command is when you can test and verify its
> functionality?
Yes, add_toolchain() would do all the same checks that happen on the
"main" toolchain when CMake starts up. The process would be:
1) add_toolchain() gets called with a FILE argument
2) the file gets loaded the same way CMAKE_TOOLCHAIN_FILE does on
startup
3) CMake performs all the same checks that it did with the "main"
toolchain
4) add_toolchain() returns and script execution resumes
So you could build the cross toolchain during configure-time and then
add it with add_toolchain(). However, I would recommend having the
toolchain build and the actual project be separate CMake projects in
order to maintain separation of responsibilities. At the very least,
I'd recommend that the cross-compiled project be a subdirectory of the
superbuild via add_subdirectory(), and the toolchain would be built in
the top directory.
> Do these targets automatically get separate binary directories so
> that the outputs don't overwrite each other?
No. In this feature, each target would get one toolchain, and *only*
one toolchain. If you want to build the same target with multiple
toolchains, you would build them as separate targets. Example:
add_executable(foo-arm foo.c bar.c TOOLCHAIN ArmToolchain)
add_executable(foo-x86_64 foo.c bar.c TOOLCHAIN x86_64Toolchain)
This could of course be abstracted away with a function():
function(make_foo toolchain)
  add_executable(foo-${toolchain} foo.c bar.c TOOLCHAIN ${toolchain})
endfunction()
make_foo(arm)
make_foo(x86_64)
My reasoning for this is that each .c/.cxx file has to be built
multiple times (once for each toolchain) anyway, so why bother trying
to make them part of the same target? Just make them separate targets.

> I assume this feature is limited only to ninja or makefile
> generators?
If Visual Studio and/or Xcode support multiple toolchains (I don't know
if they do) then it could work for them too. If not then they would
unfortunately be out of luck for multi-toolchain projects.
Kyle-- 

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


Re: [cmake-developers] Idea for Multi-Toolchain Support

2018-12-17 Thread Kyle Edwards via cmake-developers
Eric,
Thanks for the feedback. See comments below.
On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:
> > This has some common design issue as my proposal:
> > enable_cross_target(...)
> > for which Eike has valuable doubt:
> > https://cmake.org/pipermail/cmake-developers/2018-November/030919.h
> > tml 
If you're talking about the issue of specifying multiple toolchain
files on the command line, I'm imagining a design like this:
add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET})
and then specify it on the command line with:
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake
-DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake
> > So if you want to build both for host and cross toolchain you'll have to 
> > explicitely 
> > add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> > add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
> > > > If you follow the previously referred discussion you cannot assume that 
> > > > one lib/exe
> > built for a toolchain is not built for another toolchain as well.
If you want to build the same target with multiple toolchains then I
think you're better off declaring them as different targets, with
different TOOLCHAINs but the same source files, etc.
> > ... sorry wrong key pressed...
> > > > CMake could perfectly automatically create the new "TOOLCHAIN" object 
> > > > by loading the very
> > same toolchain file as we have today. We could simple add a new variable
> > CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name 
> > them as he wants.
> > When there is no CMAKE_TOOLCHAIN_NAME this would be the default
> > toolchain.
> 

My vision for this feature is that the project specifies the names of
the toolchains that it's expecting, and the toolchain file is agnostic
of this - it simply sets the properties of the toolchain named
${CMAKE_SELECTED_TOOLCHAIN}.
If you want to have a variable number of toolchains, you could do
something like this:
set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of
toolchains")
foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES})
  add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}})
  add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for
each target platform
endforeach()
Kyle-- 

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


[cmake-developers] Idea for Multi-Toolchain Support

2018-12-17 Thread Kyle Edwards via cmake-developers
Hello everyone,

One of the things that's long been requested of CMake is the ability to
have multiple toolchains - for instance, one host toolchain and one
cross toolchain, so that "utilities" needed for build can be built with
the host toolchain and then the "real" software can be built with the
cross toolchain.

To solve this problem, I would like to propose the creation of a new
first-class object type, the "toolchain" type, which would replace the
current variable-based system, similar to how imported targets replaced
variable-based usage requirements.

Every project would automatically receive one toolchain, the "DEFAULT"
toolchain, which would be either automatically configured or configured
based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
toolchains could be added with the add_toolchain() command:

add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)

Then, executables and libraries could have a toolchain specified:

add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)

Note that the TOOLCHAIN argument is optional, and if omitted, the
DEFAULT toolchain is used.

If a project uses multiple toolchains, we could have the option to
rename the default toolchain with an alternative add_toolchain()
syntax:

add_toolchain(HostToolchain DEFAULT)

Rather than adding a new toolchain, this would simply rename the
"DEFAULT" toolchain to "HostToolchain". Then the toolchain
specification for each target could look like this:

add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)

Two new global read-only properties would be added: TOOLCHAINS and
DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
the DEFAULT toolchain (which could be changed with the alternative
add_toolchain() syntax.)

The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
setting variables:

set(CMAKE_C_COMPILER /usr/bin/gcc)
set(CMAKE_C_COMPILER_ID gnu)
# etc.

it would instead set properties on the selected toolchain:

set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
/usr/bin/gcc)
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
C_COMPILER_ID gnu)
# etc.

where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
file either at the root or by the add_toolchain() command.

If you want to read the value of C_COMPILER, etc. then just use
get_property():

get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)

Obviously this system would scale well to more than just two toolchains
- just use as many add_toolchain() commands as you need.

Backwards compatibility is going to be a challenge. Both the toolchain
file and the project have to be aware of the new toolchain system,
which means we have to handle four permutations:

1) old toolchain + old project
2) old toolchain + new project
3) new toolchain + old project
4) new toolchain + new project

I propose adding a policy that both the toolchain file and the project
can set separately, and which would have a slightly different meaning
in each one. If the toolchain is OLD and the project is NEW, then the
variables set by the toolchain file would be converted into properties
on the toolchain for the project. If the toolchain is NEW and the
project is OLD, then the properties on the toolchain would be converted
into variables in the project. If both the toolchain and project have
the same value, then no special conversion is required.

I would welcome everyone's feedback on this proposal. Obviously this is
a big change to how CMake handles toolchains, and would require a lot
of very deep refactoring.

Kyle
-- 

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