/opt/mylib/include/...
/opt/mylib/lib/...
/opt/mylib/share/...
cmake's sophisticated search path should find it, at least when CMAKE_PREFIX_PATH contains /opt
uninstallation is as easy as delete a folder
It's a bit confusing what you're trying to do, but why do you need to call `makepkg -i`? Did you consider breaking that down into two steps?
1) call `makepkg`
2) call `pacman -U <pkgname>` (or `sudo pacman -U <pkgname>`)You can't use sudo with `makepkg` but you can with `pacman`.
I've considered breaking `makepkg -i` down, but the <pkgname> varies.
Still, it seems better (cleaner responsibilities) not to mix and match package manager (pacman) with build system (cmake). I'd say, either:
1) fully use cmake to manage your installation (i.e. `cmake .` then `make` then `make install`)
2) OR use pacman to manage your installation (i.e. `cmake` + `make` in `build()` in your `PKGBUILD` then `make install` in `install()` in the `PKGBUILD`).
Yes, should not mix. My first idea is to override `cmake --install .`, but it can't be done by interface of cmake, and the native implementation for `cmake --install` might still be executed accidentally, anyway it is always there, I'm going to treat it as an internal function and never for real installation.
I'll try to use CPack External Generator.
Thanks
]]>1) call `makepkg`
2) call `pacman -U <pkgname>` (or `sudo pacman -U <pkgname>`)
You can't use sudo with `makepkg` but you can with `pacman`.
Still, it seems better (cleaner responsibilities) not to mix and match package manager (pacman) with build system (cmake). I'd say, either:
1) fully use cmake to manage your installation (i.e. `cmake .` then `make` then `make install`)
2) OR use pacman to manage your installation (i.e. `cmake` + `make` in `build()` in your `PKGBUILD` then `make install` in `install()` in the `PKGBUILD`).
makepkg -e so sources are not extracted and prepare is skipped. build() calls make / ninja which should then only rebuild what has changed.
It is convenient, thanks.
]]>progandy wrote:For development you could write a PKGBUILD that reuses your development tree and remember to call it with the -"e" flag (use a small script to call it?).
I have already use configure_file to generate PKGBUILD to utilize things in CMAKE_BINARY_DIR
Do you mean cmake -E? It's mainly for crossplatform command like copy / copy_directory / echo, it might not help.
Not cmake -e, makepkg -e so sources are not extracted and prepare is skipped. build() calls make / ninja which should then only rebuild what has changed.
]]>For development you could write a PKGBUILD that reuses your development tree and remember to call it with the -"e" flag (use a small script to call it?).
I have already use configure_file to generate PKGBUILD to utilize things in CMAKE_BINARY_DIR
Do you mean cmake -E? It's mainly for crossplatform command like copy / copy_directory / echo, it might not help.
calling makepkg -i inside cmake makes no sense
trying to encapluate it by cmake
]]>It works, but it can't utilize the already built results,
Enabling ccache in makepkg.conf helps a lot with that and works with all build systems, not just cmake .
Also check https://wiki.archlinux.org/title/Makepk … and_tricks .
Good tool, but still needs to call makepkg -i manually.
]]>It works, but it can't utilize the already built results,
Enabling ccache in makepkg.conf helps a lot with that and works with all build systems, not just cmake .
Also check https://wiki.archlinux.org/title/Makepk … and_tricks .
]]>Normally, you set up cmake to install directly into the filesystem, but with an install prefix. then you write a pkgbuild that calls cmake and sets the prefix to the packaging directory.
It works, but it can't utilize the already built results, it takes extra time, cpu and disk spaces.
When developing, it is common to install/uninstall a package, clean unstallation and efficient makepkg is more important.