Re: [CMake] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Alan W. Irwin]

On 2019-02-20 17:52-0500 Timothy Wrona wrote:


I have worked on multiple C++ libraries that are built with CMake and run
Doxygen to generate HTML documentation. In every one of these libraries,
the documentation get's built into an "html" folder in the CMake "build"
directory and never gets looked at by anyone.

*Because let's be honest, most people don't like to read documentation at
all - let alone search for it.*

This leads to a few questions:

  1.

  Is there a standard location to put the documentation once it is built
  where it makes it very clear to the users of a library that documentation
  is available for a library?
  2.

  How can I ensure that every time my library is built, the documentation
  will be *automatically *updated and placed in this standard location?
  3.

  Is there any standard way to keep past versions of documentation for
  reference in case someone is using an earlier version of the library?

I have also posted this question on stack overflow. If you would like, you
can answer there instead because it may help a wider audience:
https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to


I am not aware of any standard responses to your 3 questions above.

What I do for a couple of my projects that have doxygen-generated
documentation is I have a special custom command/target that copies
the doxygen-generated documentation from the build tree back to a
special directory in the source tree, and I only invoke that target if
I am creating a source tarball.  And similarly for DocBook-generated
documentation.  Furthermore, I configure my VCS in each case to ignore
those generated directories in the source tree so there are no VCS
complications, yet tarball users get a chance to access the generated
documentation.

Of course, if someone here has a better or more standardized scheme, I would 
like to hear it.

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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-commits] CMake branch, master, updated. v3.14.0-rc2-160-geb08e68

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  eb08e68b77954a4b439ee66b4987789b213d878a (commit)
  from  0ffdcba1789dab86655bc787fc480183467573d4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb08e68b77954a4b439ee66b4987789b213d878a
commit eb08e68b77954a4b439ee66b4987789b213d878a
Author: Kitware Robot 
AuthorDate: Thu Feb 21 00:01:07 2019 -0500
Commit: Kitware Robot 
CommitDate: Thu Feb 21 00:01:07 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b324571..6687471 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 14)
-set(CMake_VERSION_PATCH 20190220)
+set(CMake_VERSION_PATCH 20190221)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] Is there an idiomatic way of setting platform specific compiler options in a generic way?

[Kuba Ober]

I am developing platform support for an embedded target (Z8 Encore!), and it 
mostly works – but I’d like to make it easier to set the compiler and linker 
flags, as there’s a ton of them: and they are nothing like GNU flags, so they 
only apply when building for that particular target. 

Thus a question: is there a preferred way for the user to set platform-specific 
flags without having to know them exactly? I’m thinking of having some sort of 
platform-agnostic means of selecting compile and link flags, and then 
translating those for the platform the target is generated for.

Specifically, I want to avoid having the following in CMakeLists for the 
project:

if("${COMPILER_ID}" strequal "ez8cc")
target_compile_options(target1 PRIVATE -const:RAM)
elseif("${COMPILER_ID}" strequal "gcc" and "${CMAKE_SYSTEM_PROCESSOR}" strequal 
"somecpu")
target_compile_definitions(target1 PRIVATE ram rom far near) # those shall be 
empty
endif()

I’d like to do something like this instead:

set_target_properties(target1 PROPERTIES  OPT_CONST RAM OPT_PACK TIGHT …)

Then, a process_target_opts() function called at the end of CMakeLists would 
iterate the targets, and for each target call process_${COMPILER_ID}_opts() (if 
such function would be present or issue a warning otherwise). That function 
then converts the OPT_ options to platform-specific flags, based on cpu and/or 
compiler.

Is it something that would be more-or-less idiomatic, or is there another 
preferred way of doing it? I really don’t want to list the options manually for 
each target/platform combo, as they’d differ quite a bit, and I have lots of 
targets (hundreds).

I’d appreciate any hints.

Cheers, Kuba Ober

-- 

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] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Timothy Wrona]

I have worked on multiple C++ libraries that are built with CMake and run
Doxygen to generate HTML documentation. In every one of these libraries,
the documentation get's built into an "html" folder in the CMake "build"
directory and never gets looked at by anyone.

*Because let's be honest, most people don't like to read documentation at
all - let alone search for it.*

This leads to a few questions:

   1.

   Is there a standard location to put the documentation once it is built
   where it makes it very clear to the users of a library that documentation
   is available for a library?
   2.

   How can I ensure that every time my library is built, the documentation
   will be *automatically *updated and placed in this standard location?
   3.

   Is there any standard way to keep past versions of documentation for
   reference in case someone is using an earlier version of the library?

I have also posted this question on stack overflow. If you would like, you
can answer there instead because it may help a wider audience:
https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to

Thanks,
Tim
-- 

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-commits] CMake branch, master, updated. v3.14.0-rc2-159-g0ffdcba

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  0ffdcba1789dab86655bc787fc480183467573d4 (commit)
   via  943a50da55f8d1b25f92dd010c4c54e3b0dfcda7 (commit)
  from  b76b83efd37a439e22d1d92af3b98c30e8f9ba97 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ffdcba1789dab86655bc787fc480183467573d4
commit 0ffdcba1789dab86655bc787fc480183467573d4
Merge: b76b83e 943a50d
Author: Craig Scott 
AuthorDate: Wed Feb 20 21:39:11 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 16:39:22 2019 -0500

Merge topic 'readme-build-out-of-source'

943a50da55 README: Suggest bootstrapping out-of-source for development

Acked-by: Kitware Robot 
Acked-by: Bartosz 
Merge-request: !2993


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=943a50da55f8d1b25f92dd010c4c54e3b0dfcda7
commit 943a50da55f8d1b25f92dd010c4c54e3b0dfcda7
Author: Brad King 
AuthorDate: Wed Feb 20 07:56:25 2019 -0500
Commit: Brad King 
CommitDate: Wed Feb 20 08:00:03 2019 -0500

README: Suggest bootstrapping out-of-source for development

Building in-source and running the test suite in-source both leave
many artifacts that we (purposely) do not cover via `.gitignore`.
For developing CMake we typically use out-of-source builds, so
suggest this in the README.

diff --git a/README.rst b/README.rst
index 11bafca..76783ec 100644
--- a/README.rst
+++ b/README.rst
@@ -57,12 +57,19 @@ You need to have a C++ compiler (supporting C++11) and a 
``make`` installed.
 Run the ``bootstrap`` script you find in the source directory of CMake.
 You can use the ``--help`` option to see the supported options.
 You may use the ``--prefix=`` option to specify a custom
-installation directory for CMake. You can run the ``bootstrap`` script from
-within the CMake source directory or any other build directory of your
-choice. Once this has finished successfully, run ``make`` and
-``make install``.  In summary::
+installation directory for CMake.  Once this has finished successfully,
+run ``make`` and ``make install``.
 
- $ ./bootstrap && make && sudo make install
+For example, if you simply want to build and install CMake from source,
+you can build directly in the source tree::
+
+  $ ./bootstrap && make && sudo make install
+
+Or, if you plan to develop CMake or otherwise run the test suite, create
+a separate build tree::
+
+  $ mkdir cmake-build && cd cmake-build
+  $ ../cmake-source/bootstrap && make
 
 Windows
 ^^^
@@ -79,9 +86,7 @@ There are two ways for building CMake under Windows:
 
  $ pacman -S --needed git base-devel mingw-w64-x86_64-gcc
 
-   and bootstrap as above::
-
- $ ./bootstrap && make
+   and bootstrap as above.
 
 .. _`CMake Download Page`: https://cmake.org/cmake/resources/software.html
 .. _`MSYS2`: https://www.msys2.org/

---

Summary of changes:
 README.rst | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] Mixted C++/Fortran library on Windows [resolved]

[Francis Giraldeau]

I just wanted to share a solution for mixing C++ and Fortran programs
on Windows using Visual Studio and Intel Fortran. The build was
failing at link time with undefined symbols comming from fortran code.
Actually, none of the fortran sources were compiled, even though it
was working fine on Linux using Makefiles.

When generating a shared library with both fortran and c++ sources like this:

add_library(mix foo.f bar.cpp)

It produces the following .vcxproj (snippet):

  


  

The None compiler, well, does nothing.

The trick is to create two libraries, one for C++ code and the other
for the fortran code:

add_library(foo foo.f)
add_library(bar bar.cpp)

Then, both .vcxproj and .vfproj gets created and the fortran code is compiled.

It might be useful to document it somewhere. Perhaps it is already
documented and I haven't found it?

Cheers,

Francis
-- 

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 Dependence on C: drive?

[Michael Jackson]

Thanks for the sanity check. I'm not really sure what is going wrong then.
Not a big deal per se but would really like to figure out what the issue
is. Maybe something funky with my PATH variable. This is on Windows 10 x64.

--
Mike Jackson

On Tue, Feb 19, 2019 at 7:21 PM J. Caleb Wherry 
wrote:

> Seems strange. Just yesterday I pulled down 3.13.4 and had no issues. I
> check cmake into our repo so it gets invoked on an assortment of different
> drives. I do the same thing you do and just change our bat config file to
> point to the new cmake binary. Never had any issues.
>
> I am running on Win7 but colleagues use Win10 and have not had any issues
> either.
>
> All that to say: shouldn’t be an issue.
>
> -Caleb
>
> On Tue, Feb 19, 2019 at 5:05 PM Michael Jackson <
> mike.jack...@bluequartz.net> wrote:
>
>> Currently using CMake 3.13.3 on Windows 10. I have “installed” cmake
>> through the .zip download and placed it in E:\DREAM3D_SDK\ 
>> cmake-3.13.3-win64-x64.
>>
>>
>>
>>
>> If I now try to use that cmake to configure my source codes I get very
>> strange errors (It cannot parse a simple project command) and then
>> complains that it cannot find a CMake_MAKE_PROGRAM matching the “-G Ninja”.
>>
>>
>>
>> I then went back to using the same version of CMake, but placed on the
>> C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the
>> past, no problems. I have a .bat file that sets up my environment with
>> needed paths and such. The ONLY difference between the 2 invocations was
>> that I changed the path to reflect the alternate location of CMake. I can
>> have 2 difference command prompts open based on this difference and one
>> works and one does not.
>>
>>
>> Was/Is there a known limitation where CMake _*must*_ be run from the C:
>> drive?
>>
>>
>>
>> --
>>
>> Michael Jackson | Owner, President
>>
>>   BlueQuartz Software
>>
>> [e] mike.jack...@bluequartz.net
>>
>> [w] www.bluequartz.net
>> --
>
>
-- 

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-commits] CMake branch, master, updated. v3.14.0-rc2-157-gb76b83e

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b76b83efd37a439e22d1d92af3b98c30e8f9ba97 (commit)
   via  e0fbb7bf0843615e805ec325432d0c6d2ef9a30e (commit)
   via  c2f6da3399efa1448eadbae65311795ced3f8930 (commit)
   via  a84e509844b74d445b654cd9d0be98a8f0e0641e (commit)
   via  d59159afdb630734213a120334f394331ef18504 (commit)
   via  0281f9a4cad6e189601a87c9ccfba8c54e71e14b (commit)
  from  b38023f958325fedd99d5480149f4958e721fdd5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b76b83efd37a439e22d1d92af3b98c30e8f9ba97
commit b76b83efd37a439e22d1d92af3b98c30e8f9ba97
Merge: e0fbb7b d59159a
Author: Brad King 
AuthorDate: Wed Feb 20 14:05:50 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:05:57 2019 -0500

Merge topic 'cray-cleanup'

d59159afdb Cray: clean up CrayPrgEnv and CrayLinuxEnvironment modules

Acked-by: Kitware Robot 
Merge-request: !2945


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e0fbb7bf0843615e805ec325432d0c6d2ef9a30e
commit e0fbb7bf0843615e805ec325432d0c6d2ef9a30e
Merge: c2f6da3 a84e509
Author: Brad King 
AuthorDate: Wed Feb 20 14:04:48 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:04:58 2019 -0500

Merge topic 'list-prepend-and-pop-subcommands'

a84e509844 list: add sub-commands PREPEND, POP_BACK, POP_FRONT

Acked-by: Kitware Robot 
Merge-request: !2980


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2f6da3399efa1448eadbae65311795ced3f8930
commit c2f6da3399efa1448eadbae65311795ced3f8930
Merge: b38023f 0281f9a
Author: Brad King 
AuthorDate: Wed Feb 20 14:01:44 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:03:48 2019 -0500

Merge topic 'configurefile-stdstring'

0281f9a4ca cmMakefile::ConfigureFile: Accept `std::string` parameters

Acked-by: Kitware Robot 
Merge-request: !2982


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a84e509844b74d445b654cd9d0be98a8f0e0641e
commit a84e509844b74d445b654cd9d0be98a8f0e0641e
Author: Alex Turbov 
AuthorDate: Mon Feb 18 00:47:50 2019 +0800
Commit: Brad King 
CommitDate: Tue Feb 19 09:42:36 2019 -0500

list: add sub-commands PREPEND, POP_BACK, POP_FRONT

diff --git a/Help/command/list.rst b/Help/command/list.rst
index bfcdf34..6c86c2a 100644
--- a/Help/command/list.rst
+++ b/Help/command/list.rst
@@ -21,6 +21,9 @@ Synopsis
 list(`APPEND`_  [...])
 list(`FILTER`_  {INCLUDE | EXCLUDE} REGEX )
 list(`INSERT`_   [...])
+list(`POP_BACK`_  [...])
+list(`POP_FRONT`_  [...])
+list(`PREPEND`_  [...])
 list(`REMOVE_ITEM`_  ...)
 list(`REMOVE_AT`_  ...)
 list(`REMOVE_DUPLICATES`_ )
@@ -33,8 +36,9 @@ Synopsis
 Introduction
 
 
-The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``REMOVE_AT``,
-``REMOVE_ITEM``, ``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create
+The list subcommands ``APPEND``, ``INSERT``, ``FILTER``, ``PREPEND``,
+``POP_BACK``, ``POP_FRONT``, ``REMOVE_AT``, ``REMOVE_ITEM``,
+``REMOVE_DUPLICATES``, ``REVERSE`` and ``SORT`` may create
 new values for the list within the current CMake variable scope.  Similar to
 the :command:`set` command, the LIST command creates new variable values in
 the current scope, even if the list itself is actually defined in a parent
@@ -142,6 +146,34 @@ For more information on regular expressions see also the
 
 Inserts elements to the list to the specified location.
 
+.. _POP_BACK:
+
+.. code-block:: cmake
+
+  list(POP_BACK  [...])
+
+If no variable name is given, removes exactly one element. Otherwise,
+assign the last element's value to the given variable and removes it,
+up to the last variable name given.
+
+.. _POP_FRONT:
+
+.. code-block:: cmake
+
+  list(POP_FRONT  [...])
+
+If no variable name is given, removes exactly one element. Otherwise,
+assign the first element's value to the given variable and removes it,
+up to the last variable name given.
+
+.. _PREPEND:
+
+.. code-block:: cmake
+
+  list(PREPEND  [ ...])
+
+Insert elements to the 0th position in the list.
+
 .. _REMOVE_ITEM:
 
 .. code-block:: cmake
diff --git a/Help/release/dev/list-prepend-and-pop-subcommands.rst 
b/Help/release/dev/list-prepend-and-pop-subcommands.rst
new file mode 100644
index 000..16b14f1
--- /dev/null
+++ b/Help/release/dev/list-prepend-and-pop-subcommands.rst
@@ -0,0 +1,4 @@
+list-prepend-and-pop-subcommands
+
+
+* :command:`list` learned new sub-commands ``PREPEND``, ``POP_FRONT`` and 
``POP_BACK``.
diff --git a/Source/cmListCommand.cxx 

Re: [CMake] [cmake-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

Okay that makes sense. I will give ExternalProject_Add a try. I think it
would be very useful if FetchContent were able to support targets with the
same name and that would be a great feature to add (although it is
understandable if it is a language limitation).

I much prefer the simplicity of FetchContent :)

Thanks,
Tim

On Wed, Feb 20, 2019 at 8:22 AM Craig Scott  wrote:

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona 
> wrote:
>
>> (Included cmake-developers list as well in case this may have just been
>> something that should work that was overlooked with the FetchContent module)
>>
>> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona 
>> wrote:
>>
>>> I am having an issue with using FetchContent to grab two subprojects
>>> that both contain a "doxygen" target to build the documentation.
>>>
>>> Both of these subprojects need to be able to be built independently and
>>> when built on their own they compile fine (along with their documentation),
>>> but when I pull them into one project using "FetchContent" I get an error
>>> saying I can't define the "doxygen" target more than once.
>>>
>>> I imagine this kind of issue would come up all of the time when using a
>>> "superbuild" pattern. Is there a typical way of handling this?
>>>
>>
> I thought this limitation was already mentioned in the FetchContent docs,
> but it seems it isn't. If two different dependencies define the same global
> target name, then they cannot be combined into the same build via
> add_subdirectory(). CMake doesn't allow a target to be redefined (although
> it does allow additional commands to be added to an existing custom
> target). I'll try to add some docs to FetchContent to mention this
> limitation, but they will not make it into the 3.14 release - the
> limitation has always been there right from when FetchContent was first
> introduced in 3.11.
>
> A traditional superbuild that uses ExternalProject won't have a problem
> with this because a subproject's own targets are not combined with targets
> of other subprojects into a single build. Instead, the top level project
> only sees the targets that ExternalProject itself creates. This is most
> likely the best workaround if you are not able to modify the target names
> used in the subprojects you want to combine.
>
> --
> 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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

Okay that makes sense. I will give ExternalProject_Add a try. I think it
would be very useful if FetchContent were able to support targets with the
same name and that would be a great feature to add (although it is
understandable if it is a language limitation).

I much prefer the simplicity of FetchContent :)

Thanks,
Tim

On Wed, Feb 20, 2019 at 8:22 AM Craig Scott  wrote:

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona 
> wrote:
>
>> (Included cmake-developers list as well in case this may have just been
>> something that should work that was overlooked with the FetchContent module)
>>
>> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona 
>> wrote:
>>
>>> I am having an issue with using FetchContent to grab two subprojects
>>> that both contain a "doxygen" target to build the documentation.
>>>
>>> Both of these subprojects need to be able to be built independently and
>>> when built on their own they compile fine (along with their documentation),
>>> but when I pull them into one project using "FetchContent" I get an error
>>> saying I can't define the "doxygen" target more than once.
>>>
>>> I imagine this kind of issue would come up all of the time when using a
>>> "superbuild" pattern. Is there a typical way of handling this?
>>>
>>
> I thought this limitation was already mentioned in the FetchContent docs,
> but it seems it isn't. If two different dependencies define the same global
> target name, then they cannot be combined into the same build via
> add_subdirectory(). CMake doesn't allow a target to be redefined (although
> it does allow additional commands to be added to an existing custom
> target). I'll try to add some docs to FetchContent to mention this
> limitation, but they will not make it into the 3.14 release - the
> limitation has always been there right from when FetchContent was first
> introduced in 3.11.
>
> A traditional superbuild that uses ExternalProject won't have a problem
> with this because a subproject's own targets are not combined with targets
> of other subprojects into a single build. Instead, the top level project
> only sees the targets that ExternalProject itself creates. This is most
> likely the best workaround if you are not able to modify the target names
> used in the subprojects you want to combine.
>
> --
> 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-developers

[Cmake-commits] CMake branch, release, updated. v3.14.0-rc2-21-g0794dd3

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  0794dd3018191ba919d9e8ada3ed18ad2b37eccd (commit)
   via  b5befac15465945d86b8c4d5603c2afd1ea29756 (commit)
   via  a4e01d6707e9cfe50b2f49f140c8a9894cd8108f (commit)
   via  4f5bb64c5628773b95f7bd66bcb6947aacced08c (commit)
   via  4dab8e69bd46b6aa85a97c4d23e9d894fc5fbcf6 (commit)
   via  35bf9ded3b116209ca864eff2da481c22117e17d (commit)
   via  da846439881dbbe3697ae42fa129031cb8f467c0 (commit)
   via  b186329d3db0083d77e61ded709f4e70a596631d (commit)
  from  13f020198fe858437f24a3fe0c349a1618e70d7b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/CMakeDetermineASMCompiler.cmake   |  2 +-
 Modules/CMakeDetermineCompilerId.cmake|  2 +-
 Modules/CMakeDetermineVSServicePack.cmake |  2 +-
 Source/cmGlobalVisualStudio14Generator.cxx| 13 +++--
 Source/cmGlobalVisualStudio14Generator.h  |  3 ++
 Source/cmGlobalVisualStudioVersionedGenerator.cxx |  6 +++
 Source/cmQtAutoGenGlobalInitializer.cxx   | 64 +++
 Source/cmQtAutoGenGlobalInitializer.h |  6 +++
 Source/cmQtAutoGenInitializer.cxx | 53 +--
 Source/cmQtAutoGenInitializer.h   |  4 ++
 10 files changed, 110 insertions(+), 45 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc2-151-gb38023f

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b38023f958325fedd99d5480149f4958e721fdd5 (commit)
   via  bb6d46d7e4f65bad099b919ffb1e34c0571ca727 (commit)
   via  8732a2b3ba81d7e512d8c317b037db5caec10ee4 (commit)
   via  462a320c8db91f4f646a19f34b9b41154019a68e (commit)
   via  7abe332cedd2d92285233ced3cdf3ecaa3eb4803 (commit)
   via  fcdd6efb724439502e9e0fa95a6c0ccb4d32a5a5 (commit)
   via  85d779442bbc9376a0c71f0dc8f42d0df52c11d4 (commit)
   via  0794dd3018191ba919d9e8ada3ed18ad2b37eccd (commit)
   via  b5befac15465945d86b8c4d5603c2afd1ea29756 (commit)
   via  a4e01d6707e9cfe50b2f49f140c8a9894cd8108f (commit)
   via  4f5bb64c5628773b95f7bd66bcb6947aacced08c (commit)
   via  4dab8e69bd46b6aa85a97c4d23e9d894fc5fbcf6 (commit)
   via  35bf9ded3b116209ca864eff2da481c22117e17d (commit)
   via  8a95808f8fb0766197ff904bc0c47ad9afa54098 (commit)
   via  da846439881dbbe3697ae42fa129031cb8f467c0 (commit)
   via  b186329d3db0083d77e61ded709f4e70a596631d (commit)
   via  c489c3e7158417b1161d46555ce1c2bcb31527fc (commit)
   via  c048cb75fcee6b31cfacdce714b343c6623f5c9c (commit)
  from  18ff514b52600a6fb37ca6fd7d38e7e3aac7129b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b38023f958325fedd99d5480149f4958e721fdd5
commit b38023f958325fedd99d5480149f4958e721fdd5
Merge: bb6d46d 8a95808
Author: Brad King 
AuthorDate: Wed Feb 20 14:02:06 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:02:51 2019 -0500

Merge topic 'optimize-cmuuid-ctor'

8a95808f8f cmUuid: Hide UUID group info in implementation

Acked-by: Kitware Robot 
Merge-request: !2976


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb6d46d7e4f65bad099b919ffb1e34c0571ca727
commit bb6d46d7e4f65bad099b919ffb1e34c0571ca727
Merge: 8732a2b c048cb7
Author: Brad King 
AuthorDate: Wed Feb 20 14:01:00 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:01:58 2019 -0500

Merge topic 'ninja-swift-partial'

c048cb75fc Ninja: add properties for Swift partial module and doc

Acked-by: Kitware Robot 
Merge-request: !2985


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8732a2b3ba81d7e512d8c317b037db5caec10ee4
commit 8732a2b3ba81d7e512d8c317b037db5caec10ee4
Merge: 462a320 c489c3e
Author: Brad King 
AuthorDate: Wed Feb 20 14:00:52 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 09:01:00 2019 -0500

Merge topic 'once-is-enough'

c489c3e715 Ninja: remove duplicate local variable (NFC)

Acked-by: Kitware Robot 
Merge-request: !2986


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=462a320c8db91f4f646a19f34b9b41154019a68e
commit 462a320c8db91f4f646a19f34b9b41154019a68e
Merge: 7abe332 0794dd3
Author: Brad King 
AuthorDate: Wed Feb 20 08:56:58 2019 -0500
Commit: Brad King 
CommitDate: Wed Feb 20 08:56:58 2019 -0500

Merge branch 'release-3.14'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7abe332cedd2d92285233ced3cdf3ecaa3eb4803
commit 7abe332cedd2d92285233ced3cdf3ecaa3eb4803
Merge: fcdd6ef b5befac
Author: Brad King 
AuthorDate: Wed Feb 20 13:55:08 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 08:55:25 2019 -0500

Merge topic 'autogen_cache_binary_checks'

b5befac154 Autogen: Use output caching GetExecutableTestOutput
a4e01d6707 Autogen: Add output caching GetExecutableTestOutput

Acked-by: Kitware Robot 
Merge-request: !2990


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcdd6efb724439502e9e0fa95a6c0ccb4d32a5a5
commit fcdd6efb724439502e9e0fa95a6c0ccb4d32a5a5
Merge: 85d7794 4dab8e6
Author: Brad King 
AuthorDate: Wed Feb 20 13:54:10 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 08:54:36 2019 -0500

Merge topic 'vs-win-sdk'

4dab8e69bd VS: Tell VS 2019 to use Windows SDK 8.1 explicitly when needed
35bf9ded3b VS: Factor out a method to set the Windows SDK version internally

Acked-by: Kitware Robot 
Merge-request: !2989


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85d779442bbc9376a0c71f0dc8f42d0df52c11d4
commit 85d779442bbc9376a0c71f0dc8f42d0df52c11d4
Merge: 18ff514 b186329
Author: Brad King 
AuthorDate: Wed Feb 20 13:53:33 2019 +
Commit: Kitware Robot 
CommitDate: Wed Feb 20 08:53:41 2019 -0500

Merge topic 'asm-no-slash-question'

b186329d3d Use -? instead of /? to test compiler for MSVC-like command-line 
support

Acked-by: Kitware Robot 
Merge-request: !2984

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

[René J . V . Bertin]

Hi,

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

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

Wrong! CMake will apparently prepend CMAKE_BINARY_DIR to these commands.

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

Thanks,

R.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Mandatory export of a static library dependency

[Lassi Niemistö]

Hello,

I use CMake 3.13RC1. My project produces, installs and exports a shared library 
target "fooshared". Some logical parts of "fooshared" are reused in an 
executable, so I have placed those sources into an internal static library 
target "barstatic". I have used target_link_libraries(fooshared barstatic) to 
make this work.

Problem: when I try to:
install(TARGETS fooshared DESTINATION  EXPORT myexport)
install(EXPORT myexport DESTINATION )
..I get a whine about dependency to "barstatic" which is not in the export 
group "myexport".

I wouldn't like to export "barstatic" at all, it should remain under the hood. 
I tried to use target_link_libraries(fooshared PRIVATE barstatic) which cut the 
export chaining, but then symbols from "barstatic" were not available for users 
of "fooshared" anymore. So I worked around this by converting "barstatic" into 
an object library, but it feels ugly.

Why would CMake require exporting statically linked dependency targets among 
the targets that use them? Feels like a bug to me...unless someone can explain 
why :)

Regards,
-Lassi Niemistö
-- 

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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Craig Scott]

On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona  wrote:

> (Included cmake-developers list as well in case this may have just been
> something that should work that was overlooked with the FetchContent module)
>
> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona 
> wrote:
>
>> I am having an issue with using FetchContent to grab two subprojects that
>> both contain a "doxygen" target to build the documentation.
>>
>> Both of these subprojects need to be able to be built independently and
>> when built on their own they compile fine (along with their documentation),
>> but when I pull them into one project using "FetchContent" I get an error
>> saying I can't define the "doxygen" target more than once.
>>
>> I imagine this kind of issue would come up all of the time when using a
>> "superbuild" pattern. Is there a typical way of handling this?
>>
>
I thought this limitation was already mentioned in the FetchContent docs,
but it seems it isn't. If two different dependencies define the same global
target name, then they cannot be combined into the same build via
add_subdirectory(). CMake doesn't allow a target to be redefined (although
it does allow additional commands to be added to an existing custom
target). I'll try to add some docs to FetchContent to mention this
limitation, but they will not make it into the 3.14 release - the
limitation has always been there right from when FetchContent was first
introduced in 3.11.

A traditional superbuild that uses ExternalProject won't have a problem
with this because a subproject's own targets are not combined with targets
of other subprojects into a single build. Instead, the top level project
only sees the targets that ExternalProject itself creates. This is most
likely the best workaround if you are not able to modify the target names
used in the subprojects you want to combine.

-- 
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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Craig Scott]

On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona  wrote:

> (Included cmake-developers list as well in case this may have just been
> something that should work that was overlooked with the FetchContent module)
>
> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona 
> wrote:
>
>> I am having an issue with using FetchContent to grab two subprojects that
>> both contain a "doxygen" target to build the documentation.
>>
>> Both of these subprojects need to be able to be built independently and
>> when built on their own they compile fine (along with their documentation),
>> but when I pull them into one project using "FetchContent" I get an error
>> saying I can't define the "doxygen" target more than once.
>>
>> I imagine this kind of issue would come up all of the time when using a
>> "superbuild" pattern. Is there a typical way of handling this?
>>
>
I thought this limitation was already mentioned in the FetchContent docs,
but it seems it isn't. If two different dependencies define the same global
target name, then they cannot be combined into the same build via
add_subdirectory(). CMake doesn't allow a target to be redefined (although
it does allow additional commands to be added to an existing custom
target). I'll try to add some docs to FetchContent to mention this
limitation, but they will not make it into the 3.14 release - the
limitation has always been there right from when FetchContent was first
introduced in 3.11.

A traditional superbuild that uses ExternalProject won't have a problem
with this because a subproject's own targets are not combined with targets
of other subprojects into a single build. Instead, the top level project
only sees the targets that ExternalProject itself creates. This is most
likely the best workaround if you are not able to modify the target names
used in the subprojects you want to combine.

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

Re: [CMake] Remove folders created by install

[Eric Noulard]

There are some possible solutions and reference here:
https://stackoverflow.com/questions/41471620/cmake-support-make-uninstall

Le sam. 16 févr. 2019 à 15:48, Felix Crazzolara 
a écrit :

> Hi everyone
>
> For my smaller projects I'd like to have 'uninstall' functionality. To
> remove installed files I can call:
>
> xargs rm < build/install_manifest.txt
>
> Unfortunately this won't delete any folders generated by the
> installation. Is there a different file that keeps track of the created
> directories, or what is the recommended way to implement such
> functionality?
>
> Example:
> Suppose that I install _some_header.hpp in
> /include// using the command install(TARGETS
>  EXPORT -targets ARCHIVE DESTINATION lib
> PUBLIC_HEADER DESTINATION include/) then I want not only
> to remove
> /include//_some_header.hpp, but also
> the directory /include//.
>
> Cheers,
>
> Felix Crazzolara
>
> --
>
> 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
>


-- 
Eric
-- 

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