[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-222-g8bc93cd

[Kitware Robot]

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  8bc93cdd797e6396040bd00eee877734af0d3759 (commit)
  from  1c73f354a36211771539bf396875bcbade8a383f (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=8bc93cdd797e6396040bd00eee877734af0d3759
commit 8bc93cdd797e6396040bd00eee877734af0d3759
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Jul 6 00:01:05 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Jul 6 00:01:05 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7421ef9..14c604f 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 9)
-set(CMake_VERSION_PATCH 20170705)
+set(CMake_VERSION_PATCH 20170706)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] cmake create executable Undefined symbols for architecture x86_64:

[Sean Wayland]

I am attempting to write a cmakelists.txt file for an application.
The application has a couple of dependencies.
I have been able to build targets for the dependencies but when I try
and add an executable for the main application I encounter this error.

Undefined symbols for architecture x86_64:

  "_main", referenced from:

 implicit entry/start for main executable

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)


Googling the error and looking on stack exchange suggests that I don't
have a main function in the implicit entry/start .

Where does it look for this function ?
Does that file need to be first in the list of sources ?



This function is included here :
${CATSMAT_DIR}/Application/CATSMAT_main.cpp

My cmake file is below.

Any advice would be appreciated I have been stuck here for a while!

Best Sean


###
# CMAKE CATSTMAT
###
cmake_minimum_required(VERSION 3.6.3)
set(CMAKE_CXX_STANDARD 14)
if(CMAKE_CONFIGURATION_TYPES)
set(CMAKE_CONFIGURATION_TYPES Debug Release)
endif()

if(UNIX)
add_definitions(-Wall -DGCC)
endif(UNIX)

# RPATH SETTING #
set(CMAKE_MACOSX_RPATH 1)

#if(APPLE)
# set (CMAKE_OSX_ARCHITECTURES "x86_64 i386")
# if (${CMAKE_SYSTEM_VERSION} VERSION_LESS 9.0.0)
# set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.4u.sdk)
# elseif (${CMAKE_SYSTEM_VERSION} VERSION_LESS 10.8.0)
# set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk)
# elseif (${XCODE_VERSION} VERSION_LESS 4.0.0)
# set (CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.6.sdk)
# else ()
# set (CMAKE_OSX_SYSROOT "macosx10.7")
# endif ()
# set (CMAKE_C++_FLAGS -mmacosx-version-min=10.4)
#endif(APPLE)
#
#if(WIN32)
# add_definitions(-DWINVER=0x0400 -DWIN32)
# if(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6")
#  add_definitions(-DVC6)
# elseif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 8 2005")
#  add_definitions(-DVC2005)
# endif(${CMAKE_GENERATOR} STREQUAL "Visual Studio 6")
#endif(WIN32)

###  BOOST LIBRARIES ###
if (APPLE)
set(BOOST_ROOT "/usr/local/boost")
set(BOOST_FILESYSTEM_LIB  /usr/local/boost/lib/libboost_filesystem.dylib)
set(BOOST_SYSTEM_LIB  /usr/local/boost/lib/libboost_system.dylib)

else (NOT APPLE)
set(BOOST_ROOT "C:/local/boost_1_58_0")
set(BOOST_FILESYSTEM_LIB  C:/local/boost_1_58_0/lib64-msvc-12.0)
set(BOOST_SYSTEM_LIB  C:/local/boost_1_58_0/lib64-msvc-12.0)
endif (APPLE)

FIND_PACKAGE( Boost 1.58.0 REQUIRED  )
INCLUDE_DIRECTORIES( ${Boost_INCLUDE_DIR} )


###
# set directories, src and headers.

set (CATSMAT_DIR/Users/seanwayland/Desktop/CATSMAT-master/catsmat/catsmat )
set (libIMUSANT_DIR${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT)
set (LOKI_DIR   ${CMAKE_CURRENT_SOURCE_DIR}/../../Loki)
set (SUFFIX_TREE_DIR${CMAKE_CURRENT_SOURCE_DIR}/../../SuffixTree)
set (GOOGLE_TEST_INC_DIR
${CMAKE_CURRENT_SOURCE_DIR}/../../googletest-master/googletest/include)
set (IMUSANT_DIR${CMAKE_CURRENT_SOURCE_DIR}/../../libIMUSANT)


set (LIBMUSICXML_DIR${CMAKE_CURRENT_SOURCE_DIR}/../../libMusicXMLv3)


 SET SOURCES EXPLICITLY #

set(SRC

${CATSMAT_DIR}/Analysis/src/IMUSANT_contour_suffixtree_builder.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_generalised_interval_suffixtree_builder.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_interval_suffixtree_builder.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_pitch_suffixtree_builder.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_repeated_interval_substring.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_t_repeated_substring.cpp
${CATSMAT_DIR}/Analysis/src/IMUSANT_VectorMapAnalysisTypes.cpp

${CATSMAT_DIR}/Application/CATSMAT_main.cpp
${CATSMAT_DIR}/Application/CATSMAT_menu.cpp

${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_chord.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_collectionvisitor.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_cp_matrix.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyad_sequences.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_dyadtuple_sequences.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_sonority_sequences.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSequences.cpp
${CATSMAT_DIR}/CounterpointAnalysis/src/CATSMAT_TrigramSuffixTreeBuilder.cpp

${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_canonic_techniques_tools.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_partdata.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_processing.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile.tpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_splitter.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_score_profile_special.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredata.cpp
${CATSMAT_DIR}/GeneralAnalysis/src/CATSMAT_scoredatacollector.cpp

${CATSMAT_DIR}/Segmentation/IMUSANT_segment.cpp
${CATSMAT_DIR}/Segmentation/IMUSANT_set_of_segment.cpp

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-221-g1c73f35

[Kitware Robot]

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  1c73f354a36211771539bf396875bcbade8a383f (commit)
   via  16d495253b45ae802ac0d78bc33f6caaa5285370 (commit)
  from  295d9bf2bd795da551d5ac266c53eeac2de45a71 (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=1c73f354a36211771539bf396875bcbade8a383f
commit 1c73f354a36211771539bf396875bcbade8a383f
Merge: 295d9bf 16d4952
Author: Brad King 
AuthorDate: Wed Jul 5 16:56:52 2017 +
Commit: Kitware Robot 
CommitDate: Wed Jul 5 12:56:55 2017 -0400

Merge topic 'clang-format-missing'

16d49525 clang-format.bash: Fix error message when clang-format is not found

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16d495253b45ae802ac0d78bc33f6caaa5285370
commit 16d495253b45ae802ac0d78bc33f6caaa5285370
Author: Brad King 
AuthorDate: Wed Jul 5 12:55:03 2017 -0400
Commit: Brad King 
CommitDate: Wed Jul 5 12:55:03 2017 -0400

clang-format.bash: Fix error message when clang-format is not found

Do not refer to a variable we just determined is empty to get the
name of the tool for the error message.  Just hard-code the name.

diff --git a/Utilities/Scripts/clang-format.bash 
b/Utilities/Scripts/clang-format.bash
index edcda77..428a9e4 100755
--- a/Utilities/Scripts/clang-format.bash
+++ b/Utilities/Scripts/clang-format.bash
@@ -92,7 +92,7 @@ fi
 
 # Verify that we have a tool.
 if ! type -p "$clang_format" >/dev/null; then
-echo "Unable to locate '$clang_format'"
+echo "Unable to locate a 'clang-format' tool."
 exit 1
 fi
 

---

Summary of changes:
 Utilities/Scripts/clang-format.bash |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.9.0-rc5-15-gef31812

[Kitware Robot]

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  ef31812ede6ca1eafd8723e8478e533deadfc4f0 (commit)
   via  83d8aceeb35d2a378777a35fea1fb7d7c2d76362 (commit)
   via  2086003145b92b2f7b7d364aa0bba69c55997b73 (commit)
   via  82a5c2c6a56af5e51c5ec8ac30fda5e145087489 (commit)
  from  d3234a8a48bbb24eff6bb1a0b1750d18c3417792 (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:
 Source/cmQtAutoGenerators.cxx |2 +-
 Source/cmVS140LinkFlagTable.h |3 ---
 Source/cmVS141LinkFlagTable.h |3 ---
 3 files changed, 1 insertion(+), 7 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-219-g295d9bf

[Kitware Robot]

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  295d9bf2bd795da551d5ac266c53eeac2de45a71 (commit)
   via  ef31812ede6ca1eafd8723e8478e533deadfc4f0 (commit)
   via  2086003145b92b2f7b7d364aa0bba69c55997b73 (commit)
  from  f973d49ab9d4c59b93f6dac812a94bb130200836 (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=295d9bf2bd795da551d5ac266c53eeac2de45a71
commit 295d9bf2bd795da551d5ac266c53eeac2de45a71
Merge: f973d49 ef31812
Author: Brad King 
AuthorDate: Wed Jul 5 10:28:38 2017 -0400
Commit: Brad King 
CommitDate: Wed Jul 5 10:28:38 2017 -0400

Merge branch 'release-3.9'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc5-216-gf973d49

[Kitware Robot]

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  f973d49ab9d4c59b93f6dac812a94bb130200836 (commit)
   via  a57b3537504c055dbd72673816a672982cc3592d (commit)
   via  83d8aceeb35d2a378777a35fea1fb7d7c2d76362 (commit)
   via  82a5c2c6a56af5e51c5ec8ac30fda5e145087489 (commit)
  from  cdb43f1c887a0695468c18968943680435c7e625 (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=f973d49ab9d4c59b93f6dac812a94bb130200836
commit f973d49ab9d4c59b93f6dac812a94bb130200836
Merge: a57b353 82a5c2c
Author: Brad King 
AuthorDate: Wed Jul 5 14:11:11 2017 +
Commit: Kitware Robot 
CommitDate: Wed Jul 5 10:11:21 2017 -0400

Merge topic 'vs-link-guard-cf'

82a5c2c6 VS: Fix support for '/guard:cf' linker flag

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a57b3537504c055dbd72673816a672982cc3592d
commit a57b3537504c055dbd72673816a672982cc3592d
Merge: cdb43f1 83d8ace
Author: Brad King 
AuthorDate: Wed Jul 5 14:10:52 2017 +
Commit: Kitware Robot 
CommitDate: Wed Jul 5 10:11:00 2017 -0400

Merge topic 'autogen-header-skip'

83d8acee Autogen: Check .moc header name against SKIP list

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83d8aceeb35d2a378777a35fea1fb7d7c2d76362
commit 83d8aceeb35d2a378777a35fea1fb7d7c2d76362
Author: Sebastian Holtermann 
AuthorDate: Fri Jun 30 13:26:18 2017 +0200
Commit: Brad King 
CommitDate: Fri Jun 30 12:53:24 2017 -0400

Autogen: Check .moc header name against SKIP list

When encountering an #include "FOO.moc" statement where
FOO.hpp was chosen over FOO.cpp as the moc source, the
FOO.hpp name was not checked against the moc SKIP list.

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index 27e4928..6d3305b 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -1003,7 +1003,7 @@ bool cmQtAutoGenerators::MocParseSourceContent(
 // In relaxed mode try to find a header instead but issue a warning
 const std::string headerToMoc =
   this->MocFindHeader(scannedFileAbsPath, incSubDir + incBasename);
-if (!headerToMoc.empty()) {
+if (!headerToMoc.empty() && !this->MocSkip(headerToMoc)) {
   // This is for KDE4 compatibility:
   fileToMoc = headerToMoc;
   if (!requiresMoc && (incBasename == scannedFileBasename)) {

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82a5c2c6a56af5e51c5ec8ac30fda5e145087489
commit 82a5c2c6a56af5e51c5ec8ac30fda5e145087489
Author: Olender, Sebastian D 
AuthorDate: Fri Jun 30 16:06:44 2017 +0200
Commit: Brad King 
CommitDate: Fri Jun 30 10:57:40 2017 -0400

VS: Fix support for '/guard:cf' linker flag

Although `$(VCTargetsPath)/1033/link.xml` for v140 and v141 toolsets
contains an entry for `LinkControlFlowGuard`, it does not work when used
in a `.vcxproj` file.  Drop our link flag table entries for these
toolsets so that the flag will be passed via `AdditionalOptions`.

diff --git a/Source/cmVS140LinkFlagTable.h b/Source/cmVS140LinkFlagTable.h
index ceb1d78..b9a4dc3 100644
--- a/Source/cmVS140LinkFlagTable.h
+++ b/Source/cmVS140LinkFlagTable.h
@@ -134,9 +134,6 @@ static cmVS7FlagTable cmVS140LinkFlagTable[] = {
   { "CLRSupportLastError", "CLRSupportLastError:SYSTEMDLL", "System Dlls Only",
 "SystemDlls", 0 },
 
-  { "LinkControlFlowGuard", "guard:cf", "Enable Security Check with Guard",
-"Guard", 0 },
-
   // Bool Properties
   { "LinkIncremental", "INCREMENTAL:NO", "", "false", 0 },
   { "LinkIncremental", "INCREMENTAL", "", "true", 0 },
diff --git a/Source/cmVS141LinkFlagTable.h b/Source/cmVS141LinkFlagTable.h
index d7faf81..8f0f1f4 100644
--- a/Source/cmVS141LinkFlagTable.h
+++ b/Source/cmVS141LinkFlagTable.h
@@ -135,9 +135,6 @@ static cmVS7FlagTable cmVS141LinkFlagTable[] = {
   { "CLRSupportLastError", "CLRSupportLastError:SYSTEMDLL", "System Dlls Only",
 "SystemDlls", 0 },
 
-  { "LinkControlFlowGuard", "guard:cf", "Enable Security Check with Guard",
-"Guard", 0 },
-
   // Bool Properties
   { "LinkIncremental", "INCREMENTAL:NO", "", "false", 0 },
   { "LinkIncremental", "INCREMENTAL", "", "true", 0 },

Re: [cmake-developers] Built-in tag support for FindDoxygen

[Robert Dailey]

I ran into an interesting situation. Originally, I had based
documentation on real targets. And in some ways, I still do, but not
directly anymore. I have some targets that are conditionally only
built on certain platforms. However, I wanted documentation for that
target to be generated regardless of platform. That means I cannot
bind a doxygen target to its real target, since it may not be there.
Everything else functions the same, and doxygen targets still build a
"mirror" of the dependency tree of the real targets amongst
themselves. Also the tag file generation happens the same way.

What I'd like to do is maybe put my doxygen CMake code (that simply
wraps doxygen_add_docs()) on a Gist for now or something, along with
some usage examples, and see what you think as far as implementation
goes. From there we can decide what needs to be integrated, or if
maybe this is a separate function provided by FindDoxygen.cmake.

I'll follow up later. Thanks for your advice.

On Fri, Jun 30, 2017 at 9:48 PM, Craig Scott  wrote:
>
>
> On Thu, Jun 29, 2017 at 11:14 AM, Robert Dailey 
> wrote:
>>
>> Doxygen supports linking external documentation together:
>> https://www.stack.nl/~dimitri/doxygen/manual/external.html
>>
>> Using doxygen_add_docs(), it doesn't provide built-in support for tag
>> files. I'm thinking this would be beneficial since the way the
>> function is designed encourages modular documentation. At least, I
>> have my projects structured like this (targets):
>>
>> A
>> A_doxygen
>> B
>> B_doxygen
>> C
>> C_doxygen
>>
>> I have 1 doxygen target per real library target. And each library has
>> dependencies on others. When library C uses something from A, I want
>> C_doxygen to link to the tagfile generated by A_doxygen.
>>
>> At the moment I'm accomplishing this by adding a target property to
>> each real target to keep track of target dependencies. Example:
>>
>> add_library(C ...)
>> target_link_libraries(C A)
>> set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)
>>
>> When I'm building A_doxygen target (using doxygen_add_docs()), I
>> specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
>> DOXYGEN_TAGFILES to point to the one output by A_doxygen.
>>
>> I don't like keeping target properties to query the dependency tree,
>> but this is the best I could come up with. Is there value in
>> incorporating this into FindDoxygen.cmake? If so, I'd like to
>> contribute it, if it's useful.
>
>
> I think there's good potential for this idea. The doxygen_add_docs()
> function could record the value of the DOXYGEN_GENERATE_TAGFILE variable in
> a target property (I'd recommend using the same name as the variable). A new
> DEPENDS option could be added to doxygen_add_docs() which would specify
> other targets this one depends on. This would invoke add_dependencies() to
> fulfil build ordering as usual, but it could also inspect the target
> properties of the dependees and if the DOXYGEN_GENERATE_TAGFILE property is
> set, then the DOXYGEN_TAGFILES variable could be augmented to pick up that
> tag file somehow. You'd have to be careful how the paths were handled to
> ensure they worked robustly, but conceptually at least I think this might be
> possible and useful. Example usage would then be something like this:
>
> # Populate DOXYGEN_GENERATE_TAGFILE if not already set,
> # use existing contents otherwise. Either way, define a target property
> # on foo which records the value.
> doxygen_add_docs(foo)
>
> # Does a similar thing as above for this target, but also picks up the
> # tag file from foo as recorded in its target properties and augments
>
> # the DOXYGEN_TAGFILES variable as appropriate.
>
> doxygen_add_docs(bar DEPENDS foo)
>
>
> You would need to be careful with how to handle contents of
> DOXYGEN_GENERATE_TAGFILE and DOXYGEN_TAGFILES that the project might already
> set. As a conservative measure, you might want to consider adding an option
> NO_AUTO_TAGFILES or similar to disable any of this logic in case a project
> does something complex and doxygen_add_docs() needs to be told to leave it
> completely up to the project to handle. The doxygen_add_docs() function was
> originally added with the intention of making it as easy as possible for
> projects to use Doxygen with minimal extra configuration, so I think having
> the auto tag handling enabled by default would probably be the right call,
> as long as there's a way for projects to disable it if needed.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
-- 

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: 

Re: [CMake] CmakeLists chain cannot find source added with add_custom_command

[J Decker]

On Wed, Jul 5, 2017 at 4:05 AM, J Decker  wrote:

> Was more of a style thing... I had (from another project) a cmakelists
> includable script that builds an amalgamation of sources (makes the
> compilation much faster overall because it doesn't have to read megs of
> headers for windows.h et al. for 50 sources but then only 1.) so I was
> updating to use this script, I already had a folder 'portable' which did
> more of a source based build instead of pulling various DLLs so it was
> like
> .../loader (the main project, that links to dlls)  included common
> amalgamation maker here
> .../loader/portable  (the static builds of the same sources) that really
> only contains a single CMakeLists.txt, so rather than use the sources,
> updated to use the amalgamation instead, and it blew up.
>
> I ended up just moving the portable/CMakeLists.txt to
> CMakeLists.portable.txt and including that instead.
>
> Just caught me off guard that it would keep custom targets private to a
> directory instead of making it globally available.  Which would complicate
> implementing this more in lots of other 'portable' (single exe, no DLL
> builds)  But I guess I could create a target that's that amalgamation
> compiled to a static library that could then be referenced by other
> projects.
>

hmm that won't work, the source has the target name compiled into it, so it
would really have to be recompiled anyway  and various other definition
options might be applied...


>
>
> On Wed, Jul 5, 2017 at 3:34 AM, Eric Noulard 
> wrote:
>
>> OK right.
>> I missed the proper FAQ entry, thanks Nicholas for pointing it out.
>>
>> Eric
>>
>> 2017-07-05 12:10 GMT+02:00 Nicholas Devenish :
>>
>>> Hi,
>>>
>>> It looks like this is the issue covered in
>>> https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_
>>> to_a_source_file_which_is_generated_in_a_subdirectory.3F
>>> and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I
>>> suppose if you are writing your own systems from scratch it's easy not
>>> to run into this, but a lot easier when converting existing
>>> complicated build systems.
>>>
>>> I kind of agree that it's easy to miss this constraint reading the
>>> documentation, but there doesn't seem to be a better suggested
>>> solution yet.
>>>
>>> Nick
>>>
>>>
>>> On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard 
>>> wrote:
>>> > Ok,
>>> >
>>> > I reproduced your issue and I can then confirm it.
>>> > I tried several thing including:
>>> >- generating the file is the buildtree
>>> >- refering to the same file with another target in the same dir
>>> >- using absolute path in the sub2/add_executable
>>> >
>>> > nothing works.
>>> > it looks like a generated file cannot be referred outside the directory
>>> > where the custom command generates it ???
>>> >
>>> > Here comes an archive with an example similar to the one descrived by
>>> J.
>>> > Decker.
>>> > If you build it without option it wokrs (because I used an intermediate
>>> > object lib)
>>> > If you (try to) build it with
>>> >
>>> > cmake -DBROKEN=1
>>> >
>>> > then it'll fails with "Cannot find source file..."
>>> >
>>> > This is definitely weird and I never encountered this after +10 years
>>> of
>>> > CMake usage!!
>>> > So I guess I have always used generated file locally to build exe or
>>> lib and
>>> > then refer to the lib.
>>> > If this is the intended behaviour then it should be documented more
>>> > explicitely.
>>> >
>>> > Now re-reading the doc of add_custom_command:
>>> >
>>> > "This defines a command to generate specified ``OUTPUT`` file(s).
>>> > A target created in the same directory (``CMakeLists.txt`` file)
>>> > that specifies any output of the custom command as a source file
>>> > is given a rule to generate the file using the command at build time."
>>> >
>>> > So the "same directory" should be underlined!! Or may be another
>>> sentence
>>> > saying that in fact you CANNOT refer to outputed files outside the
>>> > directory...
>>> >
>>> > In fact it is possible to have cross-directory reference to generated
>>> file
>>> > but this is
>>> > more like a workaround. You'll have to:
>>> >
>>> > define your custom_command and an associated custom target in dir1
>>> > define your exe/lib in dir2 and explicitely:
>>> >- flag the referred cross-dir generated source as GENERATED
>>> >- make your exe/lib depend on the cross-dir custom target in order
>>> to
>>> > trigger the file generation.
>>> >
>>> >
>>> > The second zip implement that workaround. This is nasty, I wouldn't do
>>> that.
>>> > Shall we open a bug for this misleading behavior or shall we open a
>>> bug for
>>> > doc update?
>>> >
>>> >
>>> >
>>> > 2017-07-02 10:20 GMT+02:00 J Decker :
>>> >>
>>> >> It is not generated; because it is generated during a the build phase
>>> not
>>> >> the generate phase.  So only the logical idea of the file exists.
>>> >>

Re: [CMake] CmakeLists chain cannot find source added with add_custom_command

[J Decker]

Was more of a style thing... I had (from another project) a cmakelists
includable script that builds an amalgamation of sources (makes the
compilation much faster overall because it doesn't have to read megs of
headers for windows.h et al. for 50 sources but then only 1.) so I was
updating to use this script, I already had a folder 'portable' which did
more of a source based build instead of pulling various DLLs so it was
like
.../loader (the main project, that links to dlls)  included common
amalgamation maker here
.../loader/portable  (the static builds of the same sources) that really
only contains a single CMakeLists.txt, so rather than use the sources,
updated to use the amalgamation instead, and it blew up.

I ended up just moving the portable/CMakeLists.txt to
CMakeLists.portable.txt and including that instead.

Just caught me off guard that it would keep custom targets private to a
directory instead of making it globally available.  Which would complicate
implementing this more in lots of other 'portable' (single exe, no DLL
builds)  But I guess I could create a target that's that amalgamation
compiled to a static library that could then be referenced by other
projects.



On Wed, Jul 5, 2017 at 3:34 AM, Eric Noulard  wrote:

> OK right.
> I missed the proper FAQ entry, thanks Nicholas for pointing it out.
>
> Eric
>
> 2017-07-05 12:10 GMT+02:00 Nicholas Devenish :
>
>> Hi,
>>
>> It looks like this is the issue covered in
>> https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_
>> to_a_source_file_which_is_generated_in_a_subdirectory.3F
>> and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I
>> suppose if you are writing your own systems from scratch it's easy not
>> to run into this, but a lot easier when converting existing
>> complicated build systems.
>>
>> I kind of agree that it's easy to miss this constraint reading the
>> documentation, but there doesn't seem to be a better suggested
>> solution yet.
>>
>> Nick
>>
>>
>> On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard 
>> wrote:
>> > Ok,
>> >
>> > I reproduced your issue and I can then confirm it.
>> > I tried several thing including:
>> >- generating the file is the buildtree
>> >- refering to the same file with another target in the same dir
>> >- using absolute path in the sub2/add_executable
>> >
>> > nothing works.
>> > it looks like a generated file cannot be referred outside the directory
>> > where the custom command generates it ???
>> >
>> > Here comes an archive with an example similar to the one descrived by J.
>> > Decker.
>> > If you build it without option it wokrs (because I used an intermediate
>> > object lib)
>> > If you (try to) build it with
>> >
>> > cmake -DBROKEN=1
>> >
>> > then it'll fails with "Cannot find source file..."
>> >
>> > This is definitely weird and I never encountered this after +10 years of
>> > CMake usage!!
>> > So I guess I have always used generated file locally to build exe or
>> lib and
>> > then refer to the lib.
>> > If this is the intended behaviour then it should be documented more
>> > explicitely.
>> >
>> > Now re-reading the doc of add_custom_command:
>> >
>> > "This defines a command to generate specified ``OUTPUT`` file(s).
>> > A target created in the same directory (``CMakeLists.txt`` file)
>> > that specifies any output of the custom command as a source file
>> > is given a rule to generate the file using the command at build time."
>> >
>> > So the "same directory" should be underlined!! Or may be another
>> sentence
>> > saying that in fact you CANNOT refer to outputed files outside the
>> > directory...
>> >
>> > In fact it is possible to have cross-directory reference to generated
>> file
>> > but this is
>> > more like a workaround. You'll have to:
>> >
>> > define your custom_command and an associated custom target in dir1
>> > define your exe/lib in dir2 and explicitely:
>> >- flag the referred cross-dir generated source as GENERATED
>> >- make your exe/lib depend on the cross-dir custom target in order to
>> > trigger the file generation.
>> >
>> >
>> > The second zip implement that workaround. This is nasty, I wouldn't do
>> that.
>> > Shall we open a bug for this misleading behavior or shall we open a bug
>> for
>> > doc update?
>> >
>> >
>> >
>> > 2017-07-02 10:20 GMT+02:00 J Decker :
>> >>
>> >> It is not generated; because it is generated during a the build phase
>> not
>> >> the generate phase.  So only the logical idea of the file exists.
>> >>
>> >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard 
>> >> wrote:
>> >>>
>> >>> Needless to say that your example should work but somehow CMake does
>> not
>> >>> see that the referred file is GENERATED.
>> >>>
>> >>> Le 2 juil. 2017 09:11, "Eric Noulard"  a
>> écrit :
>> 
>>  Is the referred file created?
>>  Does your actual command creating 

Re: [CMake] CmakeLists chain cannot find source added with add_custom_command

[Eric Noulard]

OK right.
I missed the proper FAQ entry, thanks Nicholas for pointing it out.

Eric

2017-07-05 12:10 GMT+02:00 Nicholas Devenish :

> Hi,
>
> It looks like this is the issue covered in
> https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_
> dependency_to_a_source_file_which_is_generated_in_a_subdirectory.3F
> and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I
> suppose if you are writing your own systems from scratch it's easy not
> to run into this, but a lot easier when converting existing
> complicated build systems.
>
> I kind of agree that it's easy to miss this constraint reading the
> documentation, but there doesn't seem to be a better suggested
> solution yet.
>
> Nick
>
>
> On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard 
> wrote:
> > Ok,
> >
> > I reproduced your issue and I can then confirm it.
> > I tried several thing including:
> >- generating the file is the buildtree
> >- refering to the same file with another target in the same dir
> >- using absolute path in the sub2/add_executable
> >
> > nothing works.
> > it looks like a generated file cannot be referred outside the directory
> > where the custom command generates it ???
> >
> > Here comes an archive with an example similar to the one descrived by J.
> > Decker.
> > If you build it without option it wokrs (because I used an intermediate
> > object lib)
> > If you (try to) build it with
> >
> > cmake -DBROKEN=1
> >
> > then it'll fails with "Cannot find source file..."
> >
> > This is definitely weird and I never encountered this after +10 years of
> > CMake usage!!
> > So I guess I have always used generated file locally to build exe or lib
> and
> > then refer to the lib.
> > If this is the intended behaviour then it should be documented more
> > explicitely.
> >
> > Now re-reading the doc of add_custom_command:
> >
> > "This defines a command to generate specified ``OUTPUT`` file(s).
> > A target created in the same directory (``CMakeLists.txt`` file)
> > that specifies any output of the custom command as a source file
> > is given a rule to generate the file using the command at build time."
> >
> > So the "same directory" should be underlined!! Or may be another sentence
> > saying that in fact you CANNOT refer to outputed files outside the
> > directory...
> >
> > In fact it is possible to have cross-directory reference to generated
> file
> > but this is
> > more like a workaround. You'll have to:
> >
> > define your custom_command and an associated custom target in dir1
> > define your exe/lib in dir2 and explicitely:
> >- flag the referred cross-dir generated source as GENERATED
> >- make your exe/lib depend on the cross-dir custom target in order to
> > trigger the file generation.
> >
> >
> > The second zip implement that workaround. This is nasty, I wouldn't do
> that.
> > Shall we open a bug for this misleading behavior or shall we open a bug
> for
> > doc update?
> >
> >
> >
> > 2017-07-02 10:20 GMT+02:00 J Decker :
> >>
> >> It is not generated; because it is generated during a the build phase
> not
> >> the generate phase.  So only the logical idea of the file exists.
> >>
> >> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard 
> >> wrote:
> >>>
> >>> Needless to say that your example should work but somehow CMake does
> not
> >>> see that the referred file is GENERATED.
> >>>
> >>> Le 2 juil. 2017 09:11, "Eric Noulard"  a
> écrit :
> 
>  Is the referred file created?
>  Does your actual command creating the file doing it in the source tree
>  and not in the build tree?
>  Are you building in-source or out of source?
> 
>  Could you give us us a toy example which shows the issue?
> 
>  Le 2 juil. 2017 04:32, "J Decker"  a écrit :
> 
>  Known issue?  Or just doesn't require a response?
> 
>  On Wed, Jun 28, 2017 at 6:05 AM, J Decker  wrote:
> >
> > I have this chain of makefiles.  It adds a custom rule to build a
> > source file, and then a subdirectory cannot reference that file.
> >
> > The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c
> > and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c
> > though it's really referencing it as
> > M:/tmp/cmake-chain/sub/sub2/../src/sack.c
> >
> > tested with 3.6.0-rc4 and 3.9.0-rc5
> >
> > if the add_custom_rule and add_executable are in the same makefile
> even
> > if there's a added path to make it not exactly the same source as the
> > 'referencing source' message logs; it works.
> >
> >
> > --- CMakeLists.txt ---
> > cmake_minimum_required(VERSION 2.8)
> >
> > message( "Adding custom rule for
> > ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" )
> >   add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c
> >   COMMAND cmake -E echo do 

Re: [CMake] CmakeLists chain cannot find source added with add_custom_command

[Nicholas Devenish]

Hi,

It looks like this is the issue covered in
https://cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_to_a_source_file_which_is_generated_in_a_subdirectory.3F
and bug https://gitlab.kitware.com/cmake/cmake/issues/14633 ? I
suppose if you are writing your own systems from scratch it's easy not
to run into this, but a lot easier when converting existing
complicated build systems.

I kind of agree that it's easy to miss this constraint reading the
documentation, but there doesn't seem to be a better suggested
solution yet.

Nick


On Sun, Jul 2, 2017 at 11:57 AM, Eric Noulard  wrote:
> Ok,
>
> I reproduced your issue and I can then confirm it.
> I tried several thing including:
>- generating the file is the buildtree
>- refering to the same file with another target in the same dir
>- using absolute path in the sub2/add_executable
>
> nothing works.
> it looks like a generated file cannot be referred outside the directory
> where the custom command generates it ???
>
> Here comes an archive with an example similar to the one descrived by J.
> Decker.
> If you build it without option it wokrs (because I used an intermediate
> object lib)
> If you (try to) build it with
>
> cmake -DBROKEN=1
>
> then it'll fails with "Cannot find source file..."
>
> This is definitely weird and I never encountered this after +10 years of
> CMake usage!!
> So I guess I have always used generated file locally to build exe or lib and
> then refer to the lib.
> If this is the intended behaviour then it should be documented more
> explicitely.
>
> Now re-reading the doc of add_custom_command:
>
> "This defines a command to generate specified ``OUTPUT`` file(s).
> A target created in the same directory (``CMakeLists.txt`` file)
> that specifies any output of the custom command as a source file
> is given a rule to generate the file using the command at build time."
>
> So the "same directory" should be underlined!! Or may be another sentence
> saying that in fact you CANNOT refer to outputed files outside the
> directory...
>
> In fact it is possible to have cross-directory reference to generated file
> but this is
> more like a workaround. You'll have to:
>
> define your custom_command and an associated custom target in dir1
> define your exe/lib in dir2 and explicitely:
>- flag the referred cross-dir generated source as GENERATED
>- make your exe/lib depend on the cross-dir custom target in order to
> trigger the file generation.
>
>
> The second zip implement that workaround. This is nasty, I wouldn't do that.
> Shall we open a bug for this misleading behavior or shall we open a bug for
> doc update?
>
>
>
> 2017-07-02 10:20 GMT+02:00 J Decker :
>>
>> It is not generated; because it is generated during a the build phase not
>> the generate phase.  So only the logical idea of the file exists.
>>
>> On Sun, Jul 2, 2017 at 12:12 AM, Eric Noulard 
>> wrote:
>>>
>>> Needless to say that your example should work but somehow CMake does not
>>> see that the referred file is GENERATED.
>>>
>>> Le 2 juil. 2017 09:11, "Eric Noulard"  a écrit :

 Is the referred file created?
 Does your actual command creating the file doing it in the source tree
 and not in the build tree?
 Are you building in-source or out of source?

 Could you give us us a toy example which shows the issue?

 Le 2 juil. 2017 04:32, "J Decker"  a écrit :

 Known issue?  Or just doesn't require a response?

 On Wed, Jun 28, 2017 at 6:05 AM, J Decker  wrote:
>
> I have this chain of makefiles.  It adds a custom rule to build a
> source file, and then a subdirectory cannot reference that file.
>
> The first is added custom rule for M:/tmp/cmake-chain/sub/src/sack.c
> and then later cannot find M:/tmp/cmake-chain/sub/src/sack.c
> though it's really referencing it as
> M:/tmp/cmake-chain/sub/sub2/../src/sack.c
>
> tested with 3.6.0-rc4 and 3.9.0-rc5
>
> if the add_custom_rule and add_executable are in the same makefile even
> if there's a added path to make it not exactly the same source as the
> 'referencing source' message logs; it works.
>
>
> --- CMakeLists.txt ---
> cmake_minimum_required(VERSION 2.8)
>
> message( "Adding custom rule for
> ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c" )
>   add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/src/sack.c
>   COMMAND cmake -E echo do something to make src/sack.c
>   )
> add_subdirectory( sub2 )
> -
>
> --- sub2/CmakeLists.txt ---
> message( "referencing source ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c"
> )
> add_executable( something ${CMAKE_CURRENT_SOURCE_DIR}/../src/sack.c )
>
> -
>
> --- Truncated output log --