In meson.build we can add something like add_global_arguments(...) or -Dcpp_args, but how can I make this specify to certain buildtype? I cannot find anything in the reference table.
You can do that by checking for the buildtype and adding the flags inside your if-check.
buildtype = get_option('buildtype')
if buildtype == 'debug'
add_project_arguments([ '-DDEBUG' ], language: 'cpp')
endif
You can find the possible values for the option on Meson's page on "Built-in options"
Related
I have two projects sharing some code. Both have their own tools for generating almost the same boilerplate code, which are defined as a CMake target that runs everything when imported (or used as dependency). Let's assume that it is called generator_A in project A and generator_B in project B.
There are components that are shared "cloned" in both projects that use this boilerplate code, so for component_1 the CMakeLists.txt on each project would have something like:
# In project A
find_package(generator_A)
add_library(component_1 ...)
target_link_libraries(component_1 generator_A)
# In project B
find_package(generator_B)
add_library(component_1 ...)
target_link_libraries(component_1 generator_B)
Apart from this and other small differences regarding the generated code, component_1 would work in both projects.
I would like to define some intermediate layer for the generators on each project, so that its usage is independent of the project and look like:
find_package(generator_unified)
add_library(component_1 ...)
target_link_libraries(component_1 generator_unified)
For reasons not under my control, I cannot change anything about the generators (e.g. names, how they work, generated code/products).
I have no idea what is the best way to do this. Some ideas that I've found searching docs and the internet:
Create a Findgenerator_unified.cmake file that defines a generator_unified::generator_unified from the products of generator_X in project_X (library, headers, other properties?). I am not really how this can be achieved, though.
Does generator_unified needs its own CMakeLists.txt file, or is it enough with the Find<>.cmake.
How can I make sure that the Find<>.cmake file is available for others?
Create some kind of alias that can be used project-wide. This doesn't look possible according to docs .
Is this a better way to achieve this? If 1st alternative is the correct,
Something like this ought to work (your first alternative):
# Findgenerator_unified.cmake
cmake_minimum_required(VERSION 3.23)
if (${CMAKE_FIND_PACKAGE_NAME}_FIND_QUIETLY)
set(quiet QUIET)
else ()
set(quiet "")
endif ()
if (${CMAKE_FIND_PACKAGE_NAME}_FIND_REQUIRED)
set(required REQUIRED)
else ()
set(required "")
endif ()
set(known_backends generator_A generator_B)
set(GENERATOR_UNIFIED_BACKEND "generator_A"
CACHE STRING "Which generator backend package to use.")
set_property(CACHE GENERATOR_UNIFIED_BACKEND
PROPERTY STRINGS "${known_backends}")
foreach (backend IN LISTS known_backends)
if (backend IN_LIST ${CMAKE_FIND_PACKAGE_NAME}_FIND_COMPONENTS)
set(GENERATOR_UNIFIED_BACKEND "${backend}")
endif ()
endforeach ()
if (GENERATOR_UNIFIED_BACKEND IN_LIST known_backends)
find_package("${GENERATOR_UNIFIED_BACKEND}" ${quiet} ${required})
set("${CMAKE_FIND_PACKAGE_NAME}_${GENERATOR_UNIFIED_BACKEND}_FOUND"
"${${GENERATOR_UNIFIED_BACKEND}_FOUND}")
endif ()
unset(known_backends)
unset(quiet)
unset(required)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(
generator_unified
HANDLE_COMPONENTS
REQUIRED_VARS "${GENERATOR_UNIFIED_BACKEND}_FOUND"
VERSION_VAR "${GENERATOR_UNIFIED_BACKEND}_VERSION"
)
if (generator_unified_FOUND AND NOT TARGET generator::unified)
add_library(generator::unified ALIAS "${GENERATOR_UNIFIED_BACKEND}")
endif ()
This is mostly boilerplate, but the key is in the last few lines... the generator::unified target is set up as an alias to whichever backend was selected.
When a consuming project goes to install a target using this, they will need to generate code that forces the backend to be the same. The HANDLE_COMPONENTS flag naturally handles this because the component name matches the sub-package name. Users will write the following snippet in their project config files:
# proj-config.cmake.in
# ...
include(FindDependencyMacro)
find_dependency(generator_unified COMPONENTS #GENERATOR_UNIFIED_BACKEND#)
# ...
I want my libraries to be generated as lib-something.so.1.0.0 and not liblib-something.so.1.0.0. For this, I used the proposals from this link: stop_preppending_'lib'_to_libs. But it seems that CMake is not able to find the library anymore.
This is what I did:
lib-something/src/CMakeLists.txt:
add_library(lib-something SHARED
${CMAKE_CURRENT_SOURCE_DIR}/Something.cpp )
set_target_properties(lib-something PROPERTIES PREFIX "")
lib-another/src/CMakeLists.txt:
add_dependencies(lib-another lib-something)
It is able to find it if I do:
add_dependencies(lib-another something)
altough my target is named 'lib-something'. I don't want that. If I were okey with having to add dependencies as 'something' I would have removed the 'lib' from the target name and it would have been enough. I find this an easy way to be identified by the users as libraries and not executables.
Any ideas?
Edited:
I also tried this:
add_library(something SHARED
${CMAKE_CURRENT_SOURCE_DIR}/Something.cpp )
set_target_properties(something PROPERTIES OUTPUT_NAME "lib-something")
In other projects:
add_dependencies(lib-another lib-something)
It works, but it looks that the generation of the libraries is also liblib...
As far as I have seen, there is no way to avoid this 'liblib' thing without changing the prefix into "", and if this prefix is changed then the library is not found no matter what.
I want to access a module description variable (a custom variable) while building an android module i.e. an executable or shared-library or prebuilt and based on its value do some extra processing on the executable or shared-lib or prebuilt.
Is there a way to do it?
Add the variable to the list of variables in clear_vars.mk , so that they get cleared when an Android.mk does include $(CLEAR_VARS)
I don't want Pelican 3.6 to generate:
/author/
/category/
/tag/
/archives.html
/authors.html
/categories.html
/tags.html
DIRECT_TEMPLATES can be set to suppress some of the index files:-
# DIRECT_TEMPLATES = ['index', 'categories', 'authors', 'archives']
DIRECT_TEMPLATES = ['index']
Omitting tag metadata in source content files will prevent generation of the tag folder and index; omitting author metadata and the AUTHOR setting will prevent generation of the author folder and index.
But it seems that suppressing category isn't so simple. I've tried setting DEFAULT_CATEGORY to an empty string, but this results in errors and no output for sources with no category metadata:-
Skipping <some_file>: could not find information about 'NameError: category'
I've also tried removing the relevant template files from the theme being used, but this merely causes them to be replaced with the matching template in the built-in "simple" theme.
Am I missing an established method of suppressing category generation?
The URL settings documentation has a long list of settings, including several […]_SAVE_AS settings. Directly below the URL settings table is a note that answers your question: for any page type that you do not want generated, set the corresponding […]_SAVE_AS setting to ''. For example, to suppress individual category page generation, add this setting:
CATEGORY_SAVE_AS = ''
I'm trying to make two packages using cmake 2.8.12: the first one contains a shared library, the second one contains headers files. Apparently, I want two packages with names libname and libname-dev respectively, so I used command install with no specified component for the shared library and the same command with COMPONENT dev for the headers files. Before this I had defined an empty default component name. So I have a code as follows:
set(CMAKE_INSTALL_DEFAULT_COMPONENT_NAME "")
install(TARGETS libname DESTINATION /usr/local/lib)
install(FILES ${header_files} DESTINATION /usr/local/include COMPONENT dev)
But as a result, despite the empty default component name libname-Unspecified and libname-dev are generated. I find this behavior quite weird, because it seems I have no way to define two packages with previously described names. Are there any ideas how to do this in any other way?
In case of debian:
Give your main component some temporary name, e.g. "runtime".
install(TARGETS my-target
COMPONENT runtime
DESTINATION ${INSTALLDIR}
)
Then remove the postfixed component name as follows:
set(CPACK_DEBIAN_RUNTIME_PACKAGE_NAME "${CPACK_PACKAGE_NAME}")
Might work with other generators, too if they provide something equivalent to "CPACK_DEBIAN_RUNTIME_PACKAGE_NAME".