Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize CMake build scripts #168

Open
ahege opened this issue Aug 23, 2022 · 6 comments
Open

Optimize CMake build scripts #168

ahege opened this issue Aug 23, 2022 · 6 comments
Assignees
Milestone

Comments

@ahege
Copy link
Collaborator

ahege commented Aug 23, 2022

Is your feature request related to a problem? Please describe.
Do some optimization on the build scripts.

Describe the solution you'd like
To be described in the comments

@ahege ahege added this to the 1.3.0 milestone Aug 23, 2022
ahege added a commit that referenced this issue Aug 24, 2022
@ahege
Copy link
Collaborator Author

ahege commented Aug 24, 2022

Optimization:

Include directories

Skipped mist of the include_directories in the executable's CMake-files. Instead we use target_include_directories (with PUBLIC) to export the include directories in the libraries. There is no need of include_directoriesin the executable's Cmake file when the library is added via target_link_libraries. The include directories are automatically imported.

Outputput directory

We now let CMake select the platform dependent output directory via cmake-generator-expression We now have one output directory per artifact. Not a self define oputput directory (we used to name 'output') where everything is build into.

E.g. Output directory (Windows) for the artifact of 'OpenScenarioReader' with 'VS2017 x64 shared' and 'Debig' configuration is resolved by cmake-generator-expressions:

/openscenario.api.test/cpp/build/cgMultiVS2017x64Shared/applications/openScenarioReader/Debug

This requires post buld steps where we copy the depenedent artifacts into the target directory. E.g. We copy the dependent dlls into /openscenario.api.test/cpp/build/cgMultiVS2017x64Shared/applications/openScenarioTester/Debug to be able to run the Tests. We use cmake-generator-expressions for these post build steps, too.

In the executable CMake files for MSVC we set the debugging working directory with:

set_target_properties( ${PROJECT_NAME} PROPERTIES VS_DEBUGGER_WORKING_DIRECTORY "$<TARGET_FILE_DIR:${PROJECT_NAME}>" )

And we aere using the cmake-generator-expression '$<TARGET_FILE_DIR:${PROJECT_NAME}>'

TODO: Transfer the new output directory into the documentation. #153

ahege added a commit that referenced this issue Aug 24, 2022
@ahege
Copy link
Collaborator Author

ahege commented Aug 24, 2022

TODO: Review workflow scripts where the output directory is explicitly defined:

/workflows/buildArtifactsForPackage.yml

@reneparis
Copy link

Hey @ahege : We're working extensively on getting the OpenScenarioLib available (and all it's dependencies) via

find_package(OpenScenarioLib REQUIRED
...
target_link_libraries(OurProject OpenScenarioLib)

Is this finally possible?

@ahege
Copy link
Collaborator Author

ahege commented Aug 24, 2022

@reneparis Yes, this should be possible. Please wait, we are working on the Linux build scripts for the dev branch.

  • First you have to fetch the content.
  • In a second step you add the library.
  • In a third step in your 'OurProject' you may copy the shared libs.

First step (from one of our projects):

Include(FetchContent)
FetchContent_Declare(
    oscLib
    GIT_REPOSITORY  https://github.com/RA-Consulting-GmbH/openscenario.api.test.git
    GIT_TAG         dev
)
	  
FetchContent_MakeAvailable(oscLib)

In a second step

target_link_libraries(OurProject OpenScenarioLib)

'OpenScenarioLib' is the name of the artifact in CMake. You may look up the way, we included the library in our OpenScenarioTester application. You probably have to set the options correctly like BUILD_SHARED_LIBS in your 'OurProject'.

As a third step, if you are using shared configuration. you may copy the shared library dependencies in your 'OurProject' as a post-build step:

To copy the antlr shared libraries:

if (BUILD_SHARED_LIBS)
       add_custom_command(TARGET OurProject
                   POST_BUILD
                   COMMAND ${CMAKE_COMMAND}
                           -E copy ${ANTLR4_RUNTIME_LIBRARIES}
						   "$<TARGET_FILE_DIR:OurProject>")
endif()

To copy the openSceanrioLib shared library

if (BUILD_SHARED_LIBS)
	add_custom_command(TARGET OurProject POST_BUILD
			COMMAND ${CMAKE_COMMAND} -E copy
					"$<TARGET_FILE:OpenScenarioLib>"
					"$<TARGET_FILE_DIR:OurProject>"
			COMMAND ${CMAKE_COMMAND} -E echo "Copying 'OpenScenarioLib' to '$<TARGET_FILE_DIR:OurProject>'"
		   )
endif()

and finally he expressionLib shared library

if (BUILD_SHARED_LIBS)
	add_custom_command(TARGET OurProject POST_BUILD
			COMMAND ${CMAKE_COMMAND} -E copy
					"$<TARGET_FILE:ExpressionLib>"
					"$<TARGET_FILE_DIR:OurProject>"
			COMMAND ${CMAKE_COMMAND} -E echo "Copying 'ExpressionLib' to '$<TARGET_FILE_DIR:OurProject>'"
		   )
endif()

@reneparis
Copy link

Hello @ahege Thanks for the answer. We'll reserve some time in our next sprint to test that.

@Deakon997 Deakon997 mentioned this issue Aug 30, 2022
6 tasks
Deakon997 added a commit that referenced this issue Aug 30, 2022
Adapted build scripts, artifact build scripts, and Linux bash scripts to reflect path changes from issue #168
@ReinhardBiegelIntech
Copy link

While using FetchContent is a feasible approach it doesn't cover the use case we have in the openPASS project. Due to build time considerations we have to fetch dependencies as binary packages (at least on the CI systems).

Of course anyone is free to pre-built their own binaries, but there would still be some cmake configuration missing (config/target files, see Config Mode). AFAIK this is the standard approach for cmake projects?

If packaging shall be included in the project itself, it might be accomplished by various mechanisms:

  • custom shell script (current situation if I understand correctly)
  • make install && zip
  • cpack
  • conan (has some really nice features)
  • ...

@ahege What are your thoughts about that?

@ahege ahege closed this as completed Aug 17, 2023
@ahege ahege reopened this Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants