Re: [CMake] Missing dll on program startup - a way automate it?

[Fred Baksik]

Adding the relevant directories to PATH in the debugger or build environment 
should allow them to be found. 

On Wed, Nov 20, 2019, at 3:32 AM, Petr Kmoch wrote:
> Hi.
> 
> I haven't used it yet, but I believe the target property 
> https://cmake.org/cmake/help/latest/prop_tgt/VS_DEBUGGER_ENVIRONMENT.html 
> might help you.
> 
> Petr
> 
> On Wed, 20 Nov 2019 at 01:02, cen  wrote:
>> Hi
>> 
>>  Perhaps not really a cmake problem but here we go. An exe depends on a 
>>  few DLLs which I ship in the repo so the rest of the devs don't have to 
>>  build them or fetch them somewhere else. Cmake finds the libraries and 
>>  project builds just fine, until you run it from VS.. you are welcomed by 
>>  the "missing dll" windows error. So I have to copy all the dlls to the 
>>  build/run folder to make it work but this is a manual step. Is there 
>>  some way in cmake/VS to somehow tell the IDE to append the execution 
>>  $PATH with all the specified library dependencies or something along 
>>  those lines? Ideally my goal is to just run cmake, open VS, build the 
>>  project and run, all automagical.
>> 
>>  I would prefer to keep the dynamic linking.
>> 
>> 
>>  Best regards, cen
>> 
>>  -- 
>> 
>>  Powered by kitware.com/cmake
>> 
>>  Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit https://cmake.org/services
>> 
>>  Visit other Kitware open-source projects at 
>> https://www.kitware.com/platforms
>> 
>>  Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>> 
>>  This mailing list is deprecated in favor of https://discourse.cmake.org
> -- 
> 
> Powered by kitware.com/cmake
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit https://cmake.org/services
> 
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> 
> This mailing list is deprecated in favor of https://discourse.cmake.org
> 
-- 

Powered by kitware.com/cmake

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

Visit other Kitware open-source projects at https://www.kitware.com/platforms

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

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] How to properly add include directories?

[Fred Baksik]

On Mon, Oct 21, 2019, at 10:16 AM, David Aldrich wrote:
> Hi again,
> 
> My CMakeLists.txt file for my shared library contains:
> 
> add_library(MyLib SHARED my_source.cpp etc.)
> target_include_directories( MyLib PRIVATE ../MyHeaders)
> 
> The library builds ok, but there is no dependency on directory ../MyHeaders - 
> touching a header file does not result in a re-compile of dependent source 
> files.
> 
> There's a discussion here:
> 
> https://stackoverflow.com/questions/13703647/how-to-properly-add-include-directories-with-cmake
>  
> Opinion seems divided over whether or not it is necessary to add the header 
> files to the list of source files for the target, e.g.:
> 
> set(SOURCES file.cpp file2.cpp ${YOUR_DIRECTORY}/file1.h 
> ${YOUR_DIRECTORY}/file2.h)
> add_library(test ${SOURCES})
> 
> Please will you tell me what is the best practice?
> -- 
> 

What generator are you using?
That thread seems to contain a lot of misunderstandings about the issue.

If you are using the Makefile generator then refer to 
https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake.
 After building the project for the first time inspect the `depend.make files 
that are generated to verify if the headers are being picked up correctly as a 
dependency.`

`--`
`F`-- 

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 link order

[Fred Baksik]

On Fri, Oct 18, 2019, at 11:55 AM, Fred Baksik wrote:
> 
> In target_link_libraries it states that "The library dependency graph is 
> normally acyclic (a DAG)". I recall from my own experience that the DAG is 
> not always created the same way when generating the project. It has to do 
> with the way with this part of CMake is implemented (C++ containers and that 
> sort of thing) so while all the inputs are the same the order is Not the same 
> so it produces a different DAG which changed the ordering of the components 
> build order which also altered the link order.
> 
> For the GHS Generator to ensure that the exact same project files are output 
> we sorted the components by name into a vector first (instead of just using a 
> set) before supplying it to this algorithm. Then the results were always the 
> same.
> 

Sorry, I wanted to clarify this a bit. The DAG is correct. For example lets say 
A depends on B and C and then C on D. This DAG always comes out the same. But 
when you try to extract the dependents of A it sometimes returns something that 
will give you B then C or C then B when accessing them in a linear order. So 
there were differences if you inspected these items with the debugger.

When I ran across these kinds of things with the GHS Generator we sort things 
in lexicographical order to produce the same results every time.

Best regards,
Fred-- 

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 link order

[Fred Baksik]

On Fri, Oct 18, 2019, at 6:24 AM, Bon, William wrote:
> Hello,
> 
> we are facing an issue while using cmake and we have no idea how to solve or 
> debug it.
> We have a complex and huge project (about 50 subdirectories and dependencies 
> everywhere), and we are facing issue regarding the link order.
> There is a lot of dependencies between those projects, and to summarize, we 
> have two libraries A and B
> A is an imported library from headers and shared lib .so declared like this
> ```
> add_library(A SHARED IMPORTED GLOBAL)
> set_target_properties(A PROPERTIES
>  IMPORTED_LINK_INTERFACE_LANGUAGES "C"
>  IMPORTED_LOCATION ${A_LIBRARY})
> ```
> 
> B is a system library part of a package.
> 
> We need to link A before B in every case.
> 
> In every project, we include A before B using
> ```
> find_package(B)
> target_link_libraries(${library_produced} PUBLIC A)
> target_link_libraries(${library_produced} PUBLIC B)
> ```
> 
> but from time to time, we don't know why, the library produced link in the 
> wrong order (checked with ldd and make VERBOSE=1).
> it links B before A.
> 
> Is there a way to find out what happens and why cmake change the link order 
> for some project and not all projects ?
> 
> Best regards,
> 
> Bill
> 

I'm going by memory when I saw something similar when updating the GHS 
Generator in CMake.

In target_link_libraries it states that "The library dependency graph is 
normally acyclic (a DAG)". I recall from my own experience that the DAG is not 
always created the same way when generating the project. It has to do with the 
way with this part of CMake is implemented (C++ containers and that sort of 
thing) so while all the inputs are the same the order is Not the same so it 
produces a different DAG which changed the ordering of the components build 
order which also altered the link order.

For the GHS Generator to ensure that the exact same project files are output we 
sorted the components by name into a vector first (instead of just using a set) 
before supplying it to this algorithm. Then the results were always the same.

But if I remember correctly an "add_dependency( B A )" or otherwise make B 
dependent on A does forces a dependency between the two libraries which forces 
the DAG to always put A before B.

I would bet that if you just did the project generation over and over again 
into different build directories you'll notice these kinds of differences in 
the different Makefiles (or whatever output that is expected by the generator).

This is how I noticed the issue with the GHS Generator because the ordering of 
some items were just changing in an unexpected fashion and I was always 
comparing what it generated against what I was expecting it to generate.

I never asked the main developers about this; and again this is just my own 
observations.

Best regards,
Fred-- 

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 to make a hierarchical application using CMake?

[Fred Baksik]

On Mon, Oct 14, 2019, at 9:13 AM, David Aldrich wrote:
> Hi

> 

> I am trying to convert a large software project from makefiles to CMake. The 
> project is organised as a set of shared ‘star’ libraries, linked to a static 
> ‘kernel’ library. The current directory arrangement is:

> 

> |--stars

> | |-- star1_lib

> | |-- source files

> | |-- makefile

> | |-- star2_lib

> | |-- source files

> | |-- makefile

> | |-- solibs

> | |-- Release

> | |-- .so files

> |

> |--kernel

> | |-- source files

> | |-- makefile

> | |-- Release

> | |-- kernel.a

> |

> |--application

>  |-- makefile

>  |-- Release

>  |-- myapp.exe

> 

> In high-level terms, how could I implement this using CMake, such that 
> invoking ‘make’ in directory ‘application’ invokes a make of each shared and 
> static library, and links them to form ‘myapp.exe’?

> 

> (I understand the basics of CMake, the issue here is how to handle the make 
> of source code and libraries spread across a directory hierarchy).

> 

> Best regards

> 

> David

> 

> 
add_subdirectory() can accept relative paths to outside the "root" source tree.
So the main CMakeLists.txt would be located in ./application.
Then do:
 add_subdirectory(../kernel kernel)
add_subdirectory(../stars/stars1_lib stars1_lib)

./kernel/CMakeLists.txt would list it's files, and etcetera.

I've use this method in the past for handling applications that are meant to 
target Windows, Linux, and embedded systems.
Then by using variables to determine with platform / target ertain kernel and 
library characteristics are used.
Everything is built in the build directory for that particular platform / 
target.
This allows for app_target1, app_target2, app_target3, ..., build directories 
to be totally independent.

--
F-- 

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] target_sources vs. PUBLIC_HEADER for libraries

[Fred Baksik]

On Fri, Oct 11, 2019, at 3:33 PM, Michael Ellery wrote:
> I’d like to make sure I understand two different aspects of header files 
> management for libraries:
> 
> (1) typically you can add header files to target_sources, but it’s only 
> helpful for IDEs..so that the IDE will show the header files in its sources 
> list, correct?. In theory, cmake does not actually need header files 
> explicitly specified for dependency tracking, although I guess listing them 
> makes it explicit.
My experience has been that adding a header file makes sure it’s listed in the 
IDE along with the other sources. Some IDEs will determine other non-listed 
headers and list them under a different folder. But I’ve never seen listing an 
unused header file getting added as a dependency so that changing it causes the 
target to get rebuilt. I’ve always had to make sure that the header is included 
in something that gets compiled. 

—
F-- 

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] extending CMAKE__LINK_EXECUTABLE

[Fred Baksik]

On Tue, Oct 8, 2019, at 9:08 AM, Setzer Sebastian (CM-CI2/ECS2) via CMake wrote:
> Dear list,

> I need to run a tool after building an executable, which will modify the 
> executable itself.

> I intend to extend the toolchain for this, because it shall be done for every 
> executable on this particular operating system.

> 

> I think for this purpose, I need to change the rule 
> CMAKE__LINK_EXECUTABLE.

> And I think I can’t put multiple commands into that rule, so I need to write 
> a wrapper which will be called instead of the normal linker, and the calls 
> the normal linker and then that special tool.

> 

> Right, so far?

> 

> Now I’d like to pass a few additional parameters to this tool, which I’d like 
> to get from a special target property.

> 

> The rule currently looks like this:

> set(CMAKE_C_LINK_EXECUTABLE "   
>   -o  ")

> 

> And I wonder what these placeholders in angle brackets mean, and if there are 
> more placeholders available. The manual doesn’t say anything about this, 
> unfortunately:

> https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_LINK_EXECUTABLE.html

> 

> Is there, for example, a way to access arbitrary target properties?

> Or do I need to hide my special parameters somewhere in the LINK_OPTIONS 
> property?

> 

> Regards,

> Sebastian

> -- 
> 

I don't see how running arbitrary commands is possible in this way.

If you want to avoid the boilerplate of adding a post-build custom command use 
a macro that performs the add_executable() and add_custom_command(). Then use 
the macro for each of the executable.

Those markers aren't specified because it is part of implementation details of 
the Makefile (and Ninja?) generator and these items tend not to be documented 
for that reason (at least that is what I have come to understand from comments 
made on gitlab and developers mailing list).

--
Fred-- 

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] Looking for an explanation: What exactly means "install" in cmake language?

[Fred Baksik]

On Mon, Oct 7, 2019, at 11:25 AM, Eric Noulard wrote:
> 
> 
> Le lun. 7 oct. 2019 à 16:49, Cornelis Bockemühl  a 
> écrit :
>> Thanks to both you and J Decker: I would say that this is still the part 
>> that I understood! So basically the word "install" in cmake language could 
>> be replaced by "copy" more or less in common human language - right?
> 
> Nope I oversimplified.
> This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is 
> updated as well.
> 

File permissions are also set according to what was specified in install() via 
`PERMISSIONS which can be different from the file permissions of the file in 
the build directory.`
`I think I saw that there was even a "make install/strip" feature that also 
stripped targets during installation.`

`I think that the word install is used consistently between GNU autotools and 
CMake:`
*2. * (Computer Science) to transfer (computer software) from a distribution 
file to a permanent location on disk, and prepare it for its particular 
environment and application.

It's that "prepare it for..." clause that makes it different from a straight up 
copy.

I don't know what may be causing your issues. I do know that at least one 
person felt that CMake installation is too aggressive in that it is always 
installing files that it doesn't need to during the installation step.

https://stackoverflow.com/questions/58069372/does-cmake-always-evaluate-install-rules-even-for-up-to-date-targets#comment102540437_58069372

--
Fred-- 

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] DEPENDS parameter of add_custom_target

[Fred Baksik]

On Mon, Oct 7, 2019, at 6:55 AM, Craig Scott wrote:
> 
> 
> On Mon, Oct 7, 2019 at 9:32 PM Setzer Sebastian (CM-CI2/ECS2) via CMake 
>  wrote:
>> Dear list,
>>  The manual says:
>> https://cmake.org/cmake/help/latest/command/add_custom_target.html
>>  Reference files and outputs of custom commands created with 
>> add_custom_command() command calls in the same directory (CMakeLists.txt 
>> file). They will be brought up to date when the target is built.
>>  Use the add_dependencies() command to add dependencies on other targets.
>> 
>>  This is different from what the manual of add_custom_command says, and 
>> would be surprising for all users who only read the manual of 
>> add_custom_command and then think they know what the parameter means for 
>> add_custom_target.
>> 
>>  But on the other hand, when I test with this:
>>  --
>>  cmake_minimum_required (VERSION 3.14)
>>  project(dependency_test LANGUAGES)
>> 
>>  add_custom_target(T1
>>  COMMAND echo T1
>>  )
>>  add_custom_target(T2
>>  COMMAND echo T2
>>  DEPENDS T1
>>  )
>> 
>>  # cmake -GNinja -B build .
>>  # ninja T2
>>  --
>>  Then T1 and T2 are built, so contrary to what the manual says, it seems to 
>> work.
>> 
>>  Is the manual just outdated (Maybe behavior has changed and only manual for 
>> add_custom_command has been updated)?
>>  Should it be the same as for add_custom_command, or are there really some 
>> differences?
> 
> As it happens, I just updated the docs for these in the last day or so. You 
> can find it in the not-yet-merged merge request here:
> 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/3891
> 
> I wrote an explanation of the specific behavior of the dependencies in the 
> associated issue here:
> 
> https://gitlab.kitware.com/cmake/cmake/issues/19771#note_635547
> 
> There is a difference between the two, but it's subtle and specific to the 
> sort of scenario I mentioned in that issue comment.
> 
> -- 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> 
> Get the hand-book for every CMake user: Professional CMake: A Practical Guide 
> 
> Consulting services (CMake, C++, build/release processes): 
> https://crascit.com/services
> -- 
> 
> 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

I found the wording for add_custom_command and add_custom_target to be 
confusing and had to look at examples (and books) to understand it better.

The DEPENDS field is kind of different for the two commands. 

It may be that add_custom_target "DEPENDS" can accept other custom targets; it 
seems from your example it does (which wouldn't surprise me from what I 
remember from the CMake source code).

For add_custom_target:
The phrase "They will be brought up to date when the target is built." had me 
thinking that this was going to force the custom command to always run.

Its more of a "The commands of add_custom_target() outputs will be run as 
needed before any add_custom_target() commands are run."

If a file listed in DEPENDS does not exist on disk then behavior is defined by 
the build tool and may or may not throw an error. I recall that Make and Ninja 
throws errors and MSBuild will have a warning.

Then there is the SOURCES field which acts like:
Similar to ``DEPENDS`` with the addition that the specified files are checked 
to exist on disk and will be added to IDE project files for convenience in 
editing.

"add_custom_target() sometimes builds SOURCES for Visual Studio generators but 
never for Makefiles"
https://gitlab.kitware.com/cmake/cmake/issues/10360

For add_custom_command it acts like (and this includes the trick that is used 
to make it always run):
If ``DEPENDS`` is not specified the command will run whenever the ``OUTPUT`` is 
missing or it will run whenever a file-level dependency is updated. If the 
command does not create one of the listed ``OUTPUT`` then the rule will always 
run. For example defining an output file called ALL or FORCE that is never 
created.

Then for the add_custom_command signature that is used for build events. You 
don't need to put the event. It defaults to POST_BUILD. This is different from 
the documentation that shows it is a required field.

--
Fred-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: