*.pri file alternative with CMake. Which is better?

bogong

Hello all!

For now trying to migrate from QMake to CMake. Could someone write any info about what is best alternative for *.pri file functionality?

Our projects have a lot of small modules which included in any project just by adding *.pri file in any *.pro. With Cmake it's not so simple in case of Qt and dependancies on QObject and etc. What is the best with CMake:

-- Just include CMakeFile manualy
-- Add like add_library()
-- Add like submodule
-- Or something else

In general want to have the same simplicity with adding modules like with *.pri file. Everything that need to be added in submodule only in inner *.pri file. Global *.pro not affected by any settings from module. What need to be in Global Cmake file and what need to be in Module Cmake file?

Christian Ehrlicher

It depends on what you're doing in the pri file.
I for example have an extra wrapper for e.g. add_executable() to set some more stuff.

JoeCFD

a .pri file is only part of a pro file and is included in the .pro file. You can write sub cmake files and include them as well. But you have to set the path to these sub cmake files. The variable name for the path is CMAKE_MODULE_PATH. These files normally have postfix .cmake and are placed under cmake or CMake dir. For exampe, if you have an abc.pri, you can create an abc.cmake which does the same things as in abc.pri . Create a dir cmake under your project dir and then move abc.cmake into cmake dir. In the CMakeList.text, add
set(CMAKE_MODULE_PATH ${CMAKE_SOURCED_DIR}/cmake)
include(abc.cmake)

Christian Ehrlicher

@JoeCFD said in *.pri file alternative with CMake. Which is better?:

include(${CMAKE_MODULE_PATH}/abc.cmake)

No need for ${CMAKE_MODULE_PATH} here when you set the module path before

JoeCFD

@Christian-Ehrlicher sure since the path has been set already.

bogong

@Christian-Ehrlicher By *.pri file encapsulating module. Everything that related to module is inside of *.pri file. In *.pro file only include of *.pri file. Nothing more. It's an attempt to simplify process of reusing code. Most of the applications developing by own or by very small team. Already developed huge amount of small modules for many cases. For now trying to migrate onto CMake almost year. Now next one attempt. My opinion for now CMake is terrible in case of cross-platform by small team, the CMake file much bigger then *.pri/*.pro files and CMake syntax is looking awful after QMake. But maybe don't know everything about it and not so experienced. We've been developing mono-platform applications and in this case CMake is very good because of a lot of functionality. But it's not so simple when covering 4 build for Android, 3 builds for iOS, 1 for MacOS, 1 for Windows from one code base within a lot of 3d-part libraries by one developer or very small team. Beside all of it HUGE amount of bugs in case of iOS. It will be very bad if Qt Company decided to drop QMake out.

bogong

@Christian-Ehrlicher The closes solution that found by my is using add_library(). But in this case have not resolved issues yet:

How to declare Qt itself globally with ability to be included in any 3-d part library automatically in the project? For now when using add_library() Qt need to be declared in each of submodule separately. It's slowing down compilation.
How to declare module includes correctly and automatically within ability to get it in any part of the project by "#include <...>"? For now it's could be added only by absolute path for me.

This is example of *.pri file that is woking perfectly for me. Everything is OK for me in this file. Trying to get the same simplicity.

bogong

@Christian-Ehrlicher Another problem that got with CMake is that CMake has linear logic and because of it sometimes you need to place module include in exact place or it will not be working at all. In case of a lot of small submodules might be very complex.

Christian Ehrlicher

@bogong said in *.pri file alternative with CMake. Which is better?:

This is example of *.pri file that is woking perfectly for me. Everything is OK for me in this file. Trying to get the same simplicity

set(SOURCES <your sources and headers from pri>)
add_library(blub STATIC ${SOURCES})
target_include_directories(blub PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}
target_link_libraries(blub PUBLIC <whatever you need)

and when you want to use this lib simply add it with target_link_libraries(myexe PUBLIC blub)

Christian Ehrlicher

@bogong said in *.pri file alternative with CMake. Which is better?:

For now when using add_library() Qt need to be declared in each of submodule separately. It's slowing down compilation.

No, add_library() is a function from cmake, not Qt

Please explain what exact you're trying to do with cmake what you did with qmake before and now it won't work.

bogong

@Christian-Ehrlicher The first trouble is adding sources from different directories. Modules located in different directories. The functionality of add_subdirectory() is not working. CMake can only add the directories that located in project root, or you need to create relative path. To just add via variable you can't.

The solution from me is:

Explicitly define all modules that used in project in outside config file and allow any developer to define any path and keep this file out of repository. In general all of it based on Global Variable scope.

set(A_DIR_MODULE_LIB1 "/path/to/Lib1")
set(A_DIR_MODULE_LIB1_BIN "${A_DIR_MODULE_LIB1}/bin")
set(A_DIR_MODULE_LIB2 "/path/to/Lib2")
set(A_DIR_MODULE_LIB2_BIN "${A_DIR_MODULE_LIB2}/bin")

Global project CMake file added in main CMake file for each of developer separately but in following one path above the repository folder. Something like this:

set(A_PROJECT_CONF "../ProjectArchitecture_v1_conf.cmake")
if(EXISTS "${A_PROJECT_CONF}")
	include("${A_PROJECT_CONF}")
else()
	message(FATAL_ERROR "No ProjectArchitecture_v1 config file")
endif()

In main CMake file add subdirectory

if(EXISTS ${A_DIR_MODULE_LIB1})
	add_subdirectory(${A_DIR_MODULE_LIB1} ${A_DIR_MODULE_LIB1_BIN})
else()
	message(FATAL_ERROR "No Lib1 cmake file: ${A_DIR_MODULE_LIB1}")
endif()

The question - is there something simpler for this kind of issues? For now all of it is kind of trick with CMake within not obvious solution.

jsulm

@bogong said in *.pri file alternative with CMake. Which is better?:

CMake can only add the directories that located in project root

This is simply wrong.
Add subdirectory relative to CMakeLists.txt where add_subdirectory is located:

add_subdirectory(sub_folder/sub_sub_folder)

bogong

@Christian-Ehrlicher Mostly all of it isn't about CMake only. It's about defining idiot-friendly developing process when the developer with low level of qualification couldn't make mistakes. Mostly all of is about developing project procedures which reflected in project architecture based on CMake instead of QMake.

bogong

@jsulm It's not wrong when different developers have different locations of modules and it must be included in one main project, using via CMake file like config. Sometimes it's impossible to define universal path for different developers. Especially when developing for mobile. Try to keep in mind not only subdirectory, but subdirectory might be different for different platforms and developers. It's allowing kind of freedom for developers when organising own environment on own laptop/desktop. This is what about:

Christian Ehrlicher

@bogong said in *.pri file alternative with CMake. Which is better?:

Mostly all of is about developing project procedures

Can be done much better with cmake - as I said you can e.g. use a custom foo_add_executable() macro which wraps up your stuff.

Sometimes it's impossible to define universal path for different developers

Fix your project structure, properly install your needed libraries to a known location, simply define your project in a way it's going to work. Has nothing to do with cmake or qmake - it's a basic project organization problem.

bogong

@Christian-Ehrlicher said in *.pri file alternative with CMake. Which is better?:

use a custom foo_add_executable() macro which wraps up your stuff.

Could you send any link on example or manual? This kind of staff isn't obvious for me yet.

Christian Ehrlicher

@bogong said in *.pri file alternative with CMake. Which is better?:

Could you send any link on example or manual?

https://cmake.org/cmake/help/latest/command/macro.html

bogong

@Christian-Ehrlicher Thx. Will read it.

Found solution that is working for me now. Got it published here

Thx to all for helpful replies.
There still unsolved for me issues with implementing Objective-C/Opjective-CPP for iOS and Java for Android when using CMake, but it will be in other threads.

Issue closed.