From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 9E22C6DE0F5A for ; Sun, 12 Jan 2020 07:08:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[AWL=-0.258, SPF_NEUTRAL=0.652] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwZmnQlqsHJ4 for ; Sun, 12 Jan 2020 07:08:03 -0800 (PST) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by arlo.cworth.org (Postfix) with ESMTP id D43606DE0F50 for ; Sun, 12 Jan 2020 07:08:02 -0800 (PST) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 83FD4100063 for ; Sun, 12 Jan 2020 17:07:56 +0200 (EET) From: Tomi Ollila To: notmuch@notmuchmail.org Subject: Re: [RFC PATCH] build: add meson build system In-Reply-To: <87ftgkiyeo.fsf@nikula.org> References: <20200111164049.8237-1-jani@nikula.org> <87r2043lzc.fsf@tethera.net> <87ftgkiyeo.fsf@nikula.org> User-Agent: Notmuch/0.28.3+84~g41389bb (https://notmuchmail.org) Emacs/25.2.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 15:08:04 -0000 On Sun, Jan 12 2020, Jani Nikula wrote: > On Sun, 12 Jan 2020, David Bremner wrote: >> Jani Nikula writes: >> >>> This is a draft patch adding basic configure, build and test support >>> for the binaries. Everything else is left out for now. It would be a >>> considerable amount of work to convert everything, and I don't expect >>> it to be possible in one go anyway. If there's interest in adding >>> meson support, it would have to happen gradually, side-by-side with >>> the current system, with a reasonably long transition period. But >>> there's no point in going beyond the patch at hand if folks decide the >>> focus should remain on the current system. >> >> Personally I think the idea is worth pursuing, but I admit I don't have >> much experience with meson/ninja. How much churn can we expect from >> meson changes? It seems there is something like one meson point release >> per month. > > I build projects with meson regularly, but I don't develop the build > files on a regular basis. So take this with a grain of salt. But I think > overall the experience has been pleasant. They do keep adding features > all the time, but AFAIK the version currently in e.g. Debian stable is > usable, and the new features don't break existing stuff. > > If you want to hold back to an older version, you might have to put more > effort to things that are easier in newer versions - but the solution > should work in all versions. Any churn would be caused by taking > advantage of the new features. > >> Are the tests supposed to be working fully in this version? When I run >> >> % meson && cd build && ninja && ninja test >> >> I get failures in T010, T351, T356, T357, T391, T395, and T710. At a >> glance it looks like mainly out-of-tree related problems to finding >> e.g. json_check_nodes.py and message-id-parse. It also looks like a few >> variables like TEST_RUBY and NOTMUCH_HAVE_PYTHON3_CFFI are not being >> set. > > I get those failures too, as I haven't bothered with debugging in more > detail yet. I just brought this to a point that mostly works. > > If we decide we can start merging meson support, it's going to be > experimental and not fully featured initially. I think we'd have to > decide what's "good enough". Obviously I think the tests must all pass, > either by fixing the issues or gracefully disabling features. For > example, I don't currently build any of notmuch-emacs or documentation - > they will require custom build rules, while all the C and C++ work out > of the box. > > I think mostly meson support can be added in parallel to the existing > system. Some things might have to be fixed for both, e.g. meson only > works with out-of-tree builds. The annoying part will be the transition > period, where you have to maintain both. And if we decide we'll want > both ad infinitum, it'll be an annoyance ad infinitum... ;) I think there are 2 options 1) make meson build system good enough we can just drop the old system (I can test how well this works on older systems out of the box -- and on my current containerized centos 6 notmuch build system =D) 2) an experimental version is merged, but no-one sending patches is expected to test that it works and someone(tm) can then update it while evolving it to fully supported system... perhaps the version tarballs would not have these so users there don't get confused 3) (the off-by-one-option) everyone is expected to keep the experimental version working while sending patches -- which would jut be painful :/ I personally like (1), but if it is not good enough (2) -- my reason for having (at least) 2 is that it provides me better opportunity to learn meson system =D > BR, > Jani. Tomi