Re: [CMake] Install without building unittests

[Scott Bloom]

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/opensource/opensource.html

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

[CMake] Install without building unittests

[Scott Bloom]

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/opensource/opensource.html

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

Re: [CMake] How can I automatically optionally build a submodule?

[Andreas Naumann]

For me, this sounds more like foo is an independent thing and not a
subdirectory.

In this case, I think about two solutions:
    1) Use a macro/function "check_yada", which sets a variable
"yada_usable". If you extract this logic in an extra .cmake file, you
can reuse it in your yada CMakelists.txt
    2) Use foo as an external project. But thats looks like a major
change in the project structure.


Am 27.03.19 um 20:05 schrieb Steve Keller:

"Albrecht Schlosser"  wrote:


If you want yadda to be optional then don't use REQUIRED.

find_package(yadda)
if (yadda_FOUND)
message(STATUS "found yadda, building bar ...")

# add your code to build bar here

endif ()

This should do what you want - unless I misunderstood your question.

This will roughly do what I want, but I think it does not correctly
express things.  For the sub-project, yadda is not optional, and if I
call cmake in that sub-project's directory, it should fail.

What I think would be appropriate would be a command
add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...)
or something similar.

Steve



--

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] How can I automatically optionally build a submodule?

[Steve Keller]

"Simon Richter"  wrote:

> With my Debian Developer hat on: please also add a mechanism to manually
> specify whether the optional component should be built. If the
> dependency changes and suddenly a component goes missing without
> triggering a build failure, that can be rather annoying for users.
>
> Without a package system, this also means that old files may stick
> around after installation, so your program should be aware that
> installed plugins could be built against an older API and weren't
> updated during the last install run.

I'd like to do that if I'd know how to achieve that using cmake.  But I find
cmake is much too large and is incapable of many things I'd expect from
a build system tool.  It also makes development ugly for the Unix accustomed
developer, only to make things portable to Windows, which I don't want anyway.

Currently, we have a shell script wrapper around cmake that does something like

if [  ]; then
BUILD_FOO=true
else
BUILD_FOO=false
fi

and in CMakeLists.txt

set(BUILD_FOO "true" CACHE BOOL "description")
...
if (BUILD_FOO)
add_subdirectory(foo)
endif()

This is *ugly* but I don't know how to do this in cmake.

Steve
-- 

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] How can I automatically optionally build a submodule?

[Steve Keller]

"Albrecht Schlosser"  wrote:

> If you want yadda to be optional then don't use REQUIRED.
>
> find_package(yadda)
> if (yadda_FOUND)
>message(STATUS "found yadda, building bar ...")
>
># add your code to build bar here
>
> endif ()
>
> This should do what you want - unless I misunderstood your question.

This will roughly do what I want, but I think it does not correctly
express things.  For the sub-project, yadda is not optional, and if I
call cmake in that sub-project's directory, it should fail.

What I think would be appropriate would be a command
add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...)
or something similar.

Steve
-- 

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] Parent component options passed to ExternalProject

[Dustyn Blasig]

Thanks for the help, I will give the FetchContent approach a shot and see
how things go. I was actually in the process of trying to do a custom
command using the built-in "cmake -E tar xvf" approach to roll a custom
FetchContent that doesn't need such a new CMake, but I can't get it to work
with zip files even though it seems like it should at this point. I'm
hoping the fetch and include as subdirectory will be a more stable approach.

On Tue, Mar 26, 2019 at 4:39 PM Craig Scott  wrote:

>
>
> On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig  wrote:
>
>> Hi All,
>>
>> I'm really struggling to use ExternalProject_Add() in our CMake project.
>>
>> Based on the documentation, I was expecting the simplest Git-based
>> external project with all defaults to act just like using a Git submodule
>> locked at a specific commit.
>>
>> include(ExternalProject)ExternalProject_Add(foobar  GIT_REPOSITORY
>> g...@github.com:FooCo/FooBar.git  GIT_TAG   origin/release/1.2.3)
>>
>> The documentation states "The default configure command runs CMake with
>> options based on the main project.", so I was expecting any options we pass
>> to the owning project such as CMAKE_INSTALL_PREFIX and other variables
>> would get propagated to the ExternalProject. However, that doesn't seem to
>> be the case. Do I need to explicitly apply every variable through the
>> "CMAKE_ARGS" options? If so,
>>
>
> Some basic details are passed down to the external project, but I don't
> recall exactly which variables. I don't think there are a lot of them and I
> do tend to find that I need to pass down some vars in my own projects. You
> may have to dig into the ExternalProject module's source to get
> confirmation for yourself, possibly also look into what the
> external_process() command's implementation does as well.
>
>
>
>> Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how
>> to make the configure step happen during the parent projects configure
>> step. Should that be happening? If not, is there a simple way to force it
>> to happen without having to duplicate everything the default options do?
>> I'm seeing mixed results with online resources, along with many older
>> examples that just don't work anymore.
>>
>
> The external project's configure step happens during the main project's
> build stage, just like every other step of ExternalProject_Add(). This will
> be the case whether you override the CONFIGURE_COMMAND or not. If you
> really need the configure step to occur during the main project's configure
> stage, then you have at least a couple of options:
>
>- Consider using the FetchContent module instead and bring the
>external project into your main build directly. If this suits your
>scenario, then I'd recommend this method. I use this a lot and it seems to
>be growing in popularity. It requires CMake 3.11 or later.
>- Go for a pure superbuild approach where your main project does
>nothing more than call various ExternalProject functions to tie together
>different external projects (i.e. your main project doesn't add any
>targets, etc. of its own). This will mean that even though the configure
>steps all occur during the main project's build step, you can control the
>dependencies between the different external projects' steps so that they
>can find what they need from each other (I'm guessing here that you want
>the external project's configure stage to run during your main project's
>build stage so that something later in your main project's configure stage
>can make use of something the external project's configure stage does). You
>will still have to explicitly specify a number of variables to be passed
>through to each external project's configure stage though, so maybe this
>doesn't solve the problem you are facing.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide 
>
-- 

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] Alternative to `add_compile_options` in Toolchain Files

[Cristian Adam]

Hi,

If your CMake version is newer than 3.11 you can control what gets into the
CMAKE__FLAGS_INIT flags with the technique from
https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/

In your case you want to remove from the linker flags init the cxx compiler
options.

Cheers
Cristian.

On Wed, Mar 27, 2019, 03:10 Jayesh Badwaik  wrote:

> Hi,
>
> In https://gitlab.kitware.com/cmake/cmake/issues/19074, it was mentioned
> that
> instead of `add_compile_options`, `CMAKE_CXX_FLAGS_INIT` should be used.
> An
> issue with this is that `CMAKE_CXX_FLAGS_INIT` flags are propogated to the
> linker as well, wherein, the linker warns about `[-Wunused-command-line-
> argument]` if those warnings are enabled.
>
> Is there an alternative to `CMAKE_CXX_FLAGS_INIT` which avoids these
> issues?
>
> Thanks
>
> --
> Best
> Jayesh Badwaik
> https://jayeshbadwaik.github.io
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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