Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add meson as an alternative to autotools with corresponding CI #300

Merged
merged 3 commits into from
Jun 28, 2024

Conversation

jluebbe
Copy link
Collaborator

@jluebbe jluebbe commented Jun 26, 2024

This adds support for meson as an alternative build system to autotools.

Copy link
Contributor

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Only superficially skimming this (and without knowing meson really...my path went autotools+c -> go+rust basically) it looks great! I'd be in favor of killing the autotools build actually.

The thing I'd like to cross-check at least manually (even in CI perhaps) is that the autotools and meson builds result in "identical" outputs...I am not aware of any reason they shouldn't actually be bit-for-bit compatible.

source_files,
c_args : composefs_hash_cflags + hidden_visibility_cflags,
dependencies : libcrypto_dep,
version : meson.project_version(), # FIXME: or libversion?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw that you have different versions for the project itself and the libcomposefs.so links. The pkgconfig file also includes a version field. Which version should go where? :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it to match what autotools produces (project version 1.0.4 in composefs.pc, libversion 1.2.0 for the symlinks).


executable('composefs-info',
['composefs-info.c', '../libcomposefs/hash.c'],
c_args : ['-DUSE_OBSTACK=0', '-DTESTING=0', '-DUSE_DIFF_HASH=0'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
This prepares for testing with meson in CI.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
@jluebbe
Copy link
Collaborator Author

jluebbe commented Jun 27, 2024

I've noticed that autotools builds both a shared and a static library, so I've updated this PR to do that as well.

@jluebbe jluebbe requested a review from cgwalters June 27, 2024 08:37
@cgwalters
Copy link
Contributor

Tried this out, it's so much faster than autotools! Nice!

Doing a diff -uNr between the two builds, I see:

--- /tmp/composefs-autotools/usr/lib64/pkgconfig/composefs.pc   2024-06-28 09:50:22.074577014 -0400
+++ /tmp/composefs-meson/usr/lib64/pkgconfig/composefs.pc       2024-06-28 09:49:34.856786643 -0400
@@ -1,13 +1,10 @@
 prefix=/usr
-exec_prefix=${prefix}
-libdir=/usr/lib64
 includedir=${prefix}/include
+libdir=${prefix}/lib64
 
-Name: Composefs
+Name: composefs
 Description: library for generating and using composefs images
 Version: 1.0.4
-Requires: 
-Requires.private:  libcrypto
+Requires.private: libcrypto
 Libs: -L${libdir} -lcomposefs
-Libs.private: -lcrypto
 Cflags: -I${includedir}

Which looks totally fine to me. Digging into the differences via diffoscope on the generated binaries and shared libraries, everything I see looks like it's an artifact of either:

  • The source paths I used were different, flowing into all the debuginfo
  • Some default linker flags are different

But that's all fine.

Thanks so much for doing this! I'm still in favor of dropping autotools; will file a tracker issue where we can debate that.

@cgwalters cgwalters merged commit d81cb87 into containers:main Jun 28, 2024
24 checks passed
@jluebbe jluebbe deleted the meson branch July 1, 2024 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants