search

genodelabs / goa

Tool for streamlining the development of Genode applications
GNU Affero General Public License v3.0
20 stars 17 forks source link

Add support for extracting api headers from src directory instead of build directory? #58

Closed jschlatow closed 1 year ago

jschlatow commented 1 year ago

Currently, the files and directories specified by an 'api' file are searched in the build directory of the library. However, it is not very common for 3rd-party libraries to copy their header files to the build directory. In order to export an api archive with Goa, one thus needs to patch the CMakeLists.txt. I'm therefore thinking about adding support for searching the specified files and directories not only in the build directory but also in the src directory.

@trimpim Does this sound reasonable to you?

trimpim commented 1 year ago

@jschlatow this is due to at least one of the libraries we build for our scenario doesn't have a nice include directory in the sources, but it only gets assembled by cmake during goa build-dir (see mails [1], [2] and [3]).

[1] https://lists.genode.org/pipermail/users/2022-December/008127.html [2] https://lists.genode.org/pipermail/users/2023-January/008181.html [3] https://lists.genode.org/pipermail/users/2023-January/008254.html

nfeske commented 1 year ago

However, it is not very common for 3rd-party libraries to copy their header files to the build directory.

That's right. However, a common pattern of autoconf-based projects is to have a config.h.in file in the source tree, which is used as template for the actual config.h file. Some projects make quite extensive use of such transformations from .h.in files to .h files (not merely config.h) depending on the ./configure results. I'm afraid that there is no way around extracting these generated parts of the API from the build directory.

That said, if you discover ways for simplifying the api extraction while largely avoiding heuristics, I'm all for it.

jschlatow commented 1 year ago

@nfeske Yes, I understand that there is the need to extract generated header files from the build directory. I was rather thinking of adding a mechanism for looking up the specified files/directories first in the build directory and, if they do not exist, in the src directory.

I'm still pondering about alternatives, though. A general issue is that many libraries do not cleanly place their header files in an include directory. For non-generated headers, this could be solved during import (using DIRS and DIR_CONTENT). For generated headers, though, we will probably need to patch the CMakeLists.txt anyway. Another direction could be to somehow express in the api file where the files are searched for and what directory they are supposed to be placed in the api archive. Yet, I'm afraid the result would be syntactic clutter.

jschlatow commented 1 year ago

I'm wondering whether the cleaner solution would be to make use of make install. Most libraries should be able to install themselves including header files. In case of cmake, the install directory can be specified by providing an --install-prefix argument. This step would only be necessary for api archives. Once the install directory has been populated, we can extract the header files from this directory instead of the build directory.

nfeske commented 1 year ago

Sounds good. In autoconf.tcl (and I believe qmake.tcl), we already happen to use make install because the install directory is also useful for picking up build artifacts.

jschlatow commented 1 year ago

Implemented by 8b9f700

trimpim commented 1 year ago

@jschlatow I'm currently trying this out (current staging 45f2aa3). Sorry for the delay.

For two of our libraries/binaries seem to ignore the --instal-prefix they still want to install to /usr/local/, which fails because of obvious reasons.

I was able to work around by adding the line below to the cmake_args file.

-DCMAKE_INSTALL_PREFIX:string=install

With this the files ware placed below: var/build/x86_64/install/ which is is what the --install-prefix you set does, if I understand it correct.

jschlatow commented 1 year ago

@trimpim Could you have a look into the generated cmake_install.cmake files of the two libraries that still want to install into /usr/local and check to what the CMAKE_INSTALL_PREFIX default value is set and whether there are any hard coded occurrences of /usr/local? You may also send me the corresponding CMakeList.txt files via email so that I can have a look at what is done differently.

trimpim commented 1 year ago

@jschlatow I tested latest staging on two machines (Ubuntu 20.04 real hardware and Debian 12 virtual machine) with latest staging.

The result differs:

cmake --version:

https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html lists --instal-prefix as new feature in version 3.21.

jschlatow commented 1 year ago

@trimpim Thanks a lot for the detailed investigation. Since --install-prefix simply maps to CMAKE_INSTALL_PREFIX, I'd rather set the latter directly to stay compatible with older cmake installations. May you give 16674dc a try?

trimpim commented 1 year ago

@jschlatow I only tested it on Ubuntu 20.04. It worked as intended, the headers were installed in var/build/x86_64/install/