GNOME Bugzilla – Bug 783642
Add meson build system
Last modified: 2017-08-10 08:23:34 UTC
This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Created attachment 353546 [details] [review] Add meson build system
Created attachment 353629 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Created attachment 353630 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Carlos: you should be now able to create the tarball by running "ninja release"
Created attachment 353633 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Created attachment 353634 [details] [review] Remove nmake scripts Now if you need to build libgxps with visual studio you should use meson.
Created attachment 353635 [details] [review] Remove autotools build system If you need to build libgxps use meson instead.
Created attachment 353636 [details] [review] Automatically generate the pkgconfig file
Created attachment 353652 [details] [review] RELEASING: update the instructions
Created attachment 353655 [details] [review] Remove HAVE_CONFIG_H define This is not needed anymore since we have it always defined.
Review of attachment 353633 [details] [review]: I haven't looked at it very thoroughly but here's one thing I've noticed. ::: meson.build @@ +18,3 @@ +# should only happen during development cycles, otherwise the +# interface age is the same as the micro version +if gxps_minor_version.is_odd() I don't think gxps uses even/odd to distinguish release and development versions. @@ +24,3 @@ +endif + +soversion = 0 soversion needs to be set to 2 to match the current SONAME. @@ +29,3 @@ +# revision = interface +current = gxps_minor_version * 100 + gxps_micro_version - gxps_interface_age +revision = gxps_interface_age This is taken from graphene? This library versioning is very different from the current libtool versioning scheme. Maybe that doesn't matter because I don't think anything really makes use of libtool's current/revision/age system but the soversion above is important.
Created attachment 353675 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Created attachment 353680 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
Now the version should be fine
Created attachment 353708 [details] [review] Add meson build system This build system will initially serve to replace the nmake script and later on to also replace autotools once we are happy with the quality.
I've tested this over the last couple days and it's working well. I think the library versioning instructions should be added back to RELEASING and added to the top level meson.build though. Carlos, do you have any comments?
(In reply to Jason Crain from comment #16) > I've tested this over the last couple days and it's working well. I think > the library versioning instructions should be added back to RELEASING and > added to the top level meson.build though. > > Carlos, do you have any comments? I agree, I've just pushed the patches with those modifications. There one more problem. The installation is different, I don't know if it's because I'm using meson wrong, I've run it passing only --prefix, like with autotools. Everything built ok, but the installation path is different. The library is now installed to $prefix/lib/x86_64-linux-gnu/, while I have all my libs in $prefix/lib/ directly. And the pkg-config file is now in $prefix/lib/x86_64-linux-gnu/pkgconfig. I don't have those paths in my LD_LIBRARY_PATH/PKG_CONFIG_PATH so now I have two versions installed and evince only finds the old one.
Comment on attachment 353636 [details] [review] Automatically generate the pkgconfig file I had forgotten this, pushed now too.
(In reply to Carlos Garcia Campos from comment #17) > (In reply to Jason Crain from comment #16) > > I've tested this over the last couple days and it's working well. I think > > the library versioning instructions should be added back to RELEASING and > > added to the top level meson.build though. > > > > Carlos, do you have any comments? > > I agree, I've just pushed the patches with those modifications. There one > more problem. The installation is different, I don't know if it's because > I'm using meson wrong, I've run it passing only --prefix, like with > autotools. Everything built ok, but the installation path is different. The > library is now installed to $prefix/lib/x86_64-linux-gnu/, while I have all > my libs in $prefix/lib/ directly. And the pkg-config file is now in > $prefix/lib/x86_64-linux-gnu/pkgconfig. I don't have those paths in my > LD_LIBRARY_PATH/PKG_CONFIG_PATH so now I have two versions installed and > evince only finds the old one. I know I can get the old behavior by passing also --libdir to meson, but I prefer if we don't change the defaults.
Meson guesses the libdir based on OS. lib/x86_64-linux-gnu is a default for a Debian-derived distro. You can change that by adding this line to the top-level meson.build: diff --git a/meson.build b/meson.build index 9a35c39..83a203c 100644 --- a/meson.build +++ b/meson.build @@ -1,7 +1,8 @@ project('libgxps', 'c', version: '0.2.5', default_options: [ - 'buildtype=debugoptimized' + 'buildtype=debugoptimized', + 'libdir=lib' ], license: 'LGPL2+', meson_version: '>= 0.36.0') The caveat is that downstream (Debian, RedHat, etc) will now have to specify --libdir instead of relying on meson's defaults.
I think we should keep meson defaults. Then we change jhbuild and it is a matter of just running jhbuild make
Is it expected to see GXPS-0.1.gir got renamed to Gxps-1.0.gir?
That's definitely a regression
(In reply to Jason Crain from comment #20) > Meson guesses the libdir based on OS. lib/x86_64-linux-gnu is a default for > a Debian-derived distro. You can change that by adding this line to the > top-level meson.build: > > diff --git a/meson.build b/meson.build > index 9a35c39..83a203c 100644 > --- a/meson.build > +++ b/meson.build > @@ -1,7 +1,8 @@ > project('libgxps', 'c', > version: '0.2.5', > default_options: [ > - 'buildtype=debugoptimized' > + 'buildtype=debugoptimized', > + 'libdir=lib' > ], > license: 'LGPL2+', > meson_version: '>= 0.36.0') > > The caveat is that downstream (Debian, RedHat, etc) will now have to specify > --libdir instead of relying on meson's defaults. As they have always done, I guess. I don't like changing the defaults only because we change the build system, but if other gnome modules are doing this, and distros expect that, I'm fine then.
Another problem is that we have always included the html generated api documentation in tarballs, that the current dist script is no longer doing.
Created attachment 354543 [details] [review] meson: fix apiversion to 0.1 This way the gir is generated with the right version
(In reply to Carlos Garcia Campos from comment #25) > Another problem is that we have always included the html generated api > documentation in tarballs, that the current dist script is no longer doing. Yeah, not sure what the best way for that is...
Review of attachment 354543 [details] [review]: I think we also have to change the gnome.generate_gir call to use 'GXPS' namespace instead of 'Gxps'.
Created attachment 354648 [details] [review] gir: change namespace to GXPS
Attachment 354543 [details] pushed as c3ada8f - meson: fix apiversion to 0.1 Attachment 354648 [details] pushed as 4b1d92b - gir: change namespace to GXPS
The one small thing you forgot to include is any information whatsoever of how to actually use your fancy new buildsystem to, you know, actually build the software.
Tom Hughes: In case you are after snarky comments, "you know", please see https://wiki.gnome.org/Foundation/CodeOfConduct - thanks!
Hey Tom, just have a look at the documentation of meson: http://mesonbuild.com/Running-Meson.html
Sorry if it came across as snarky but a two minute job of updating a Fedora package to a new version had just turned into a thirty minute nightmare :-( I did eventually find that web page from the, distinctly minimal meson man page but it is itself fairly minimal and in general mesonbuild.com does a poor job of distinguishing content for people trying to run meson from content (the vast majority of it) for people trying to write meson build scripts. Think I have it done now anyway (https://src.fedoraproject.org/rpms/libgxps/c/9d2e825ad21fbcfa0e99c2f9632859788cd9803c?branch=master).
Tom, there are other modules that are already using meson. Please check i.e with Kalev if you need help, he probably updated some of the modules