I know how to create a .deb package with simple project using dpkg --build project in structure
( project ( bin (source files), debian (controlfile) ))
but in case of complete project with Makefiles, can't copy the project bin folder.
what to add in makefile so project gets builds also create .deb package with "make" command?
where to store DEBIAN directory with control file?
Related
I have a git repo with many many projects in it. I am trying to use MSVC with Clang-cl and CMake, Git.
I started out building a project directly in MSVC:
CMakePresets.json
CMakeLists.txt
asource.file.cpp
When I was happy with the working code, I moved these files into /repo/subfolder, and committed them.
Now I am cloning my repo as a new project: I chose to "clone repository" at MSVC project creation, and I want to avoid building the /repo root CMake project. Instead I want to build the /repo/subfolder CMake project. How can I achieve this?
Imagine I am on the Linux command line. Instead of:
cd myrepo
mkdir -p build && pushd build
cmake .. -G Ninja
I want to:
cd myrepo/subfolder
mkdir -p build && pushd build
cmake .. -G Ninja
The difference is that I want to make use of a CMake project in a subfolder instead of the root folder. I have been unable to build anything but the root project.
I've tried:
Right-click CMakeLists.txt and Configure CMake - it configures the top-level CMake project instead of the file I am clicking on.
Right-click CMakePresets.json and click all the "Add..." etc. there. It seems to edit the presets file itself.
I could not figure out how to have many CMake builds in one project cloned from a repo, but I figured out how to open any folder as its own CMake project:
File -> Open -> CMake...
Select the subfolder as your project. Then MSVC will trample your CMakePresets.json (truncating it to 0 bytes) which you can reset with Git -> Undo Changes. Once you have undone the changes you will want to reset the CMake cache and reconfigure in order to avoid failed CMake compilation tests.
And now it should work. Unfortunately it doesn't seem to be very easy to clone a repo and then work with $project inside it.
We have multiple libraries in different folder, The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
I am able to build the libraries present in other folders using add_subdirectory() in a loop, but I am not able to install them to output folder by main cmake file. Could anyone help me out on this.
The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
It is not necessary in CMake to install libraries in order to link to them. You can build the libraries and have your main executable link to them without installing the libraries. When you need to install your application as a whole, you can install libraries along with the executable if needed i.e. if the libraries are shared ones and not static ones.
One example of how you can organize things: assume you have the following structure in your project:
CMakeLists.txt # root of project
|
|--lib
| |--CMakeLists.txt # library subproject
|
|--app
|--CMakeLists.txt # app subproject
Then your root CMakeLists.txt can look like this:
project(MyProject)
add_subdirectory(lib)
add_subdirectory(app)
The lib subproject's CMakeLists.txt can look like this:
project(MyLib)
set(SOURCES <...>) # specify library's sources
add_library(${PROJECT_NAME} ${SOURCES})
set(MyLib ${PROJECT_NAME} CACHE INTERNAL "")
The last line in the snippet above is aimed to make MyLib variable available everywhere within the project. I found this trick here and used it successfully in my projects. Maybe there are better options here, if anyone knows them, feel free to suggest.
The app's CMakeLists.txt can then look like this:
project(MyApp)
set(SOURCES <...>) # specify app's sources
add_executable(${PROJECT_NAME} ${SOURCES})
target_link_libraries(${PROJECT_NAME} ${MyLib})
I haven't covered the installation here but it's actually straightforward: if your libraries are static ones, you only need to install the executable using install TARGETS. If your libraries are shared ones, you need to install them along with the executable.
I am using cmake to build and install my C++ application. I have a custom install directory set by:
set(CMAKE_INSTALL_PREFIX /home/user/release/myproj)
and I use make install to install the binaries and libraries to this custom install location. Is there a way to clean the destination directory every time I call make install to clean up possible old binaries in this installation dir?
You can remove files using the file command in cmake. Here is an example to remove old binaries, just define EXECUTABLE_OUTPUT_PATH:
file(GLOB MY_FILES ${EXECUTABLE_OUTPUT_PATH}/*)
if (MY_FILES)
file (REMOVE ${MY_FILES})
endif()
Using CMake 2.8 on Windows 10, Intel compiler.
I'm building all 4 combinations of {debug, release}, {32bit, 64bit}, and want all build intermediates (e.g. obj) to be placed in 4 separate folders accordingly, relative to the project folder.
Tried setting:
CMAKE_CURRENT_BINARY_DIR
CMAKE_BINARY_DIR
PROJECT_BINARY_DIR
CMAKE_CACHEFILE_DIR
CMAKE_RUNTIME_OUTPUT_DIRECTORY
To no avail, and all the products end up in the project folder (where the CMakeLists.txt resides).
All build artifacts are placed in the directory cmake was run from (NOT necessarily where CMakeLists.txt resides).
So, for each configuration simply CD into the desired output directory and run cmake from there.
I have created a PackageMaker (OSX) Installer that successfully installs two items, a main file, and a folder of files (with root), within '/Applications/[specific Application folder]/' path. Now I want to make sure the installer doesn't install the folder if it already exists (but I do want to overwrite the main file). Pretty basic, I'm sure ... but how is this best done?
Standard procedure:
You will have to create two component packages- one for the main file and the other for the folder of files.
Now in your Distribution script, you can disable the installation of second package based on the existence of the folder on the system.
Workaround:
Use your preinstall script to rename the existing folder on the system, let the new folder get installed, and then from the postinstall script, delete the newly installed folder and rename the older package back to the original name.