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

Building with Meson #621

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

Leiaz
Copy link
Collaborator

@Leiaz Leiaz commented Mar 31, 2018

I just wanted to try this Meson everyone is talking about on an actual application. This is not really a pull request, I just wanted to share it, if anyone want to try. It can't coexist with autotools as written. I modified some files to use only gettext and no longer use intltool (maybe we should do that with autotools too), and I moved the icons to just install the directory, not rewrite the path for each icon.

I like it. It doesn't vomit files all over the source tree. The build files are very readable. It automatically generates a compile_commands.json, which is used by tools like YouCompleteMe vim plugin. It doesn't have separate instructions for dist : it packages the latest commit in version control (compiling and testing it first).

Meson supports gettext. Recent gettext can handle xml, desktop files,
making intltool unnecessary.
This also modifies desktop, appdata and xslt files to use gettext
(removing underscores).
@mikelolasagasti
Copy link
Contributor

@Leiaz do you plan to work on this PR to make it mergeable again? If not, I can continue the work

@Leiaz
Copy link
Collaborator Author

Leiaz commented Oct 11, 2020

@mikelolasagasti No I didn't really plan to, as I don't see the point unless @lwindolf is interested in merging it. I'm not using it, because when I build Liferea to test changes, I need to do it the way it is going to be released anyway.
So yes, you can do it, if you are interested.

@lwindolf
Copy link
Owner

@Leiaz @mikelolasagasti I'm not against Meson if the overhead (in declaration and release commands) is less then with autotools I'd be happy with it. We should also think of the downstream maintainers whether Meson works good for them too (I have no clue how useful it is for them).

In general I personally think autotools has seen so little improvement over time, it is time to give some other project a chance.

@Leiaz
Copy link
Collaborator Author

Leiaz commented Oct 12, 2020

@lwindolf It is the build system used by multiple GNOME projects, like gtk, evince, Epiphany ... I think that is where I read about it. So packagers shouldn't have a problem adapting their scripts. Maybe we could wait for a big version change, so it will be less of a surprise ?

@lwindolf
Copy link
Owner

I wouldn't wait as 1.13.x is defined (in the release tags) as unstable so breaking stuff it ok per definition.

@mikelolasagasti
Copy link
Contributor

Meson builds are faster (tested with cached sudo):

(master)
/usr/bin/time  -p sh -c 'meson _build/  ; ninja -C _build/ ; sudo ninja -C _build/ install'
 
real 11.06
user 49.54
sys 7.70

(13.3)
/usr/bin/time  -p sh -c './autogen.sh ; ./configure ; make -j9 ; sudo make install'
real 17.06
user 56.73
sys 9.33

From maintainers perspective, a project I work on migrated to Meson and Fedora, Debian, openSUSE and Arch created new packages/recipes same day, so I don't think it would be a problem for downstream packaging.

I've updated this PR locally and I need to check if i18n works fine before creating a new PR.

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.

None yet

3 participants