patchelf
patchelf copied to clipboard
NixOS
added cmake build
Hi @linux-fan-dave, do you mind sharing some details regarding the purpose of this PR?
Looks like @linux-fan-dave prefers CMake over autotools, and I share this preference.
Ups sorry. I thought I did provide a description. I simply added a CMake build file as a alternative to the autotools build. If you already use CMake it is really easy to add dependencies to other CMake projects. Autotools do not integrate quite as nice.
This cmake script is not equivalent to the autotools one. Differences I can find:
- Does not autodetect page size.
- Does not include tests.
- Enables C++11 mode
- Does not install manpage
Would the CMake build file be accepted if it were without the mentioned problems? To 1: What does autoedect page size mean? I saw a default in the configure and a paramter that can overwrite the auto. This is the behaviour in cmake as well. It has a default / auto and a paramter that can be used to overwrite. To 2: Yes this is true. Could be done. To 3: I was not able to compile without C++11 enabled - but I could investigate further. To 4: I could add that.
@linux-fan-dave I am not a maintainer so I can't answer your overall question (but in general I like cmake more than autotools so +1 from me). Of course you should wait to see if the maintainer wants this change before doing more work on this.
As to 1, there is this line in configure that queries getconf to ask for the page size: https://github.com/NixOS/patchelf/blob/4034c6d/configure.ac#L17
Moreover, your parameter is not overridable in the command line. It should probably use the CACHE option, and provide a short help string.
If you already use CMake it is really easy to add dependencies to other CMake projects. Autotools do not integrate quite as nice.
I don't get what dependencies you mean. Is there some other task than locating the patchelf executable? Surely cmake can handle that easily already. EDIT: please, no offense meant; it's more about my curiosity ;-)
In general, cmake allows you to easly "add_subproject()" which is useful when you want to link (for example statically) against another library, then cmake will build another cmake project as dependency and provide you the thing.
Here however, patchelf is a application not library, so no much useful.
This said, CMake sucks much less than Autotools and I am honestly surprised when i see a software that is not from '90 but decide to start with autotools. If I could I would replace autotools everywhere with CMake. :)
I'm getting off-topic: my experience is that autotools-based tend to be more robust – when you have some "unusual" demands, and I was surprised by that. In particular I dealt with wanting to put different parts of the application to different prefixes (--libdir, --mandir) which worked mostly flawlessly on more than a hundred nixpkgs packages, and I did some cross-compilation.
EDIT: I don't mean to deny that much of autotools feels terribly hacky and it's showing its age, but I don't think the situation is as clear as "cmake is always better for new projects". (Besides, patchelf is over ten years old now.)
In our case we have a cmake based project which needs to patch some binaries before beeing deployed. We therefore included patchelf as a third party project to our project and compile it. It therefore can be used in a postbuild step. A cmake based project can easily be added to our project, whilst using the autotools from our cmake build is a bit of a hassle. If there is any interest in adding it to patchelf - I would fix the problems with cmake to be added upstream to patchelf.
to detect automatically Linux PAGE_SIZE you could write cmake execute_process!
Something like this will do the trick
execute_process(COMMAND ${CMAKE_COMMAND} getconf PAGESIZE OUTPUT_VARIABLE PAGE_SIZE_VAR)
add_definition (-DPAGE_SIZE=${PAGE_SIZE_VAR})
But untested though...
I added Meson on my fork. I can create a PR if you are interested. It compiles successfully with muon + samurai (neither Python nor a C++ compiler are required, only a C99 compiler). That being said, tests are not yet implemented.
Both cmake and meson projects should be added, the community must address the bugs until the projects are 100% compatible with the autotools stuff.
The maintainer only has to mention in the readme file that only the autotools project is officially supported, any bug in the other projects is ignored unless the community provides patches, sounds reasonable doesn't it?
And perhaps to avoid any confusion, the projects should go inside a subdir, i.e. contrib, and should be able to run from that location. This is what lz4 does
When it comes to cross-compiling, autotools offers the shortest solution (--build=xxx --host=yyy), but other build systems offer better syntax (specially meson), several times faster configure, out-of-tree builds, support for Windows and non-posix systems, etc...
