Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Thu, Nov 01, 2018 at 06:38:03PM -0700, Andrew Gregory wrote: > On 11/01/18 at 08:51pm, Dave Reisner wrote: > > On Thu, Nov 01, 2018 at 01:03:27AM -0700, Andrew Gregory wrote: > > > On 10/21/18 at 05:46pm, Dave Reisner wrote: > > ... > > > > > +libcommon = static_library( > > > > + 'common', > > > > + libcommon_sources, > > > > + install : false) > > > > > > It's a mistake, but common/ini.c currently includes alpm.h, which > > > grabs the system alpm.h, or dies if it's not installed, because this > > > doesn't link_with libalpm. I'll send a patch to fix this particular > > > error, but I can imagine this sort of subtle error creeping in again. > > > Should we proactively link_with libalpm to prevent this from > > > recurring? > > > > I get what you're saying about ini.c wrongly including alpm.h, but I'm > > not sure I follow about linking with libalpm. Shouldn't the includes be > > fixed such that the inclusion of alpm.h comes from lib/libalpm rather > > than /usr/include? I'm not clear on what linking with the local libalpm > > accomplishes other than being an unnecessary dependency. > > I've still not played with meson enough to fully understand exactly > how it works. The use of link_with was just to get meson to use > lib/libalpm as an include dir. If there's a better way to do that, > great, I just want to make sure that if a common file includes alpm.h > in the future, it doesn't sneakily use the system copy. Ah yes, we're saying the same thing. Fixed on my branch.
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 11/01/18 at 08:51pm, Dave Reisner wrote: > On Thu, Nov 01, 2018 at 01:03:27AM -0700, Andrew Gregory wrote: > > On 10/21/18 at 05:46pm, Dave Reisner wrote: ... > > > +libcommon = static_library( > > > + 'common', > > > + libcommon_sources, > > > + install : false) > > > > It's a mistake, but common/ini.c currently includes alpm.h, which > > grabs the system alpm.h, or dies if it's not installed, because this > > doesn't link_with libalpm. I'll send a patch to fix this particular > > error, but I can imagine this sort of subtle error creeping in again. > > Should we proactively link_with libalpm to prevent this from > > recurring? > > I get what you're saying about ini.c wrongly including alpm.h, but I'm > not sure I follow about linking with libalpm. Shouldn't the includes be > fixed such that the inclusion of alpm.h comes from lib/libalpm rather > than /usr/include? I'm not clear on what linking with the local libalpm > accomplishes other than being an unnecessary dependency. I've still not played with meson enough to fully understand exactly how it works. The use of link_with was just to get meson to use lib/libalpm as an include dir. If there's a better way to do that, great, I just want to make sure that if a common file includes alpm.h in the future, it doesn't sneakily use the system copy.
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Thu, Nov 01, 2018 at 01:03:27AM -0700, Andrew Gregory wrote:
> On 10/21/18 at 05:46pm, Dave Reisner wrote:
>
> -- >8 -- (lots of words)
>
> > diff --git a/meson.build b/meson.build
> > new file mode 100644
> > index ..3f9b2ae0
> > --- /dev/null
> > +++ b/meson.build
> > @@ -0,0 +1,487 @@
>
> -- >8 -- (many more words)
>
> > +PYTHON = find_program('python')
>
> This should look for python3, should it not?
>
> -- >8 -- (I really hope this was mostly copy-paste)
>
> > +libcommon = static_library(
> > + 'common',
> > + libcommon_sources,
> > + install : false)
>
> It's a mistake, but common/ini.c currently includes alpm.h, which
> grabs the system alpm.h, or dies if it's not installed, because this
> doesn't link_with libalpm. I'll send a patch to fix this particular
> error, but I can imagine this sort of subtle error creeping in again.
> Should we proactively link_with libalpm to prevent this from
> recurring?
>
I get what you're saying about ini.c wrongly including alpm.h, but I'm
not sure I follow about linking with libalpm. Shouldn't the includes be
fixed such that the inclusion of alpm.h comes from lib/libalpm rather
than /usr/include? I'm not clear on what linking with the local libalpm
accomplishes other than being an unnecessary dependency.
> -- >8 -- (seriously, this patch is huge)
>
> > diff --git a/test/pacman/meson.build b/test/pacman/meson.build
> > new file mode 100644
> > index ..dbdb429e
> > --- /dev/null
> > +++ b/test/pacman/meson.build
> > @@ -0,0 +1,357 @@
> > +pacman_tests = [
> > + { 'name': 'tests/backup001.py' },
>
> Having the test list and expected success/failure duplicated here is
> almost certain to lead to meson and autotools getting out of sync.
> Can/should we dynamically create this list at least for as long as
> we're maintaining both build systems?
I'll think about how to do this... I'm not crazy about the idea of
making configuration of the meson build anything more than just 'meson
build', and this all needs to ready for processing at the time meson
generates the inputs for ninja.
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 10/21/18 at 05:46pm, Dave Reisner wrote:
-- >8 -- (lots of words)
> diff --git a/meson.build b/meson.build
> new file mode 100644
> index ..3f9b2ae0
> --- /dev/null
> +++ b/meson.build
> @@ -0,0 +1,487 @@
-- >8 -- (many more words)
> +PYTHON = find_program('python')
This should look for python3, should it not?
-- >8 -- (I really hope this was mostly copy-paste)
> +libcommon = static_library(
> + 'common',
> + libcommon_sources,
> + install : false)
It's a mistake, but common/ini.c currently includes alpm.h, which
grabs the system alpm.h, or dies if it's not installed, because this
doesn't link_with libalpm. I'll send a patch to fix this particular
error, but I can imagine this sort of subtle error creeping in again.
Should we proactively link_with libalpm to prevent this from
recurring?
-- >8 -- (seriously, this patch is huge)
> diff --git a/test/pacman/meson.build b/test/pacman/meson.build
> new file mode 100644
> index ..dbdb429e
> --- /dev/null
> +++ b/test/pacman/meson.build
> @@ -0,0 +1,357 @@
> +pacman_tests = [
> + { 'name': 'tests/backup001.py' },
Having the test list and expected success/failure duplicated here is
almost certain to lead to meson and autotools getting out of sync.
Can/should we dynamically create this list at least for as long as
we're maintaining both build systems?
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Sun, Oct 21, 2018 at 10:11:18PM -0400, Dave Reisner wrote: > On Mon, Oct 22, 2018 at 11:16:25AM +1000, Allan McRae wrote: > > On 22/10/18 10:03 am, Dave Reisner wrote: > > > On Mon, Oct 22, 2018 at 09:56:04AM +1000, Allan McRae wrote: > > >> On 22/10/18 8:57 am, Eli Schwartz wrote: > > Also, most projects ship prebuilt man pages. I think some GNU ones > > commit the built page to the tree, so that could be an option. > > >> > > >>> Both those things are also true about the configure and Makefile.in > > >>> files... > > >> > > >> That is another good reason not to use git archive to create release > > >> tarballs. > > >> > > >> A > > > > > > Consider that the reason we need 'make dist' and can't just use 'git > > > archive' is because autotools *requires* extra tooling around just to > > > generate the build system. This is no longer needed with meson. > > > > Good point! I'm not overly familiar with meson, so missed that completely. > > > > > Pre-generating the manpages means that our substitutions are > > > invalidated. For example, someone building from the tarball with > > > --prefix=/some/where/else or no --prefix at all will have a > > > pacman.conf(5) that still claims the right path is /etc/pacman.conf > > > > > > I understand your point about python2 vs python3, but I think that's > > > something we can work out based on a python3-based asciidoc in > > > existance. > > > > Does the meson build script allow us to not create docs if wanted? > > Yes, see the meson_options.txt as part of this patch. One can invoke > meson with -Ddoc=disabled to prevent manpages from being built. > > > > What problems here would you like to see solved for the inclusion of > > > meson? That will help me focus my time spent on this. > > > > None need solved for inclusion in the current state. I'm just trying to > > understand what our future release process will look like. > > Great! > > > While we have autotools in parallel, if I run "make dist" with this > > patch, do all the needed meson files get included too? Can we get a > > helper script to run doxygen? > > No, meson.build files will not be included with the autotools-built > 'make dist' tarball. It feels weird to do this. I suspect that if we > want to switch the Arch build over while this dual build-system world > exists, we should just build from a tag in the git repo. > > Yes, I can add a script in build-aux to invoke doxygen. It's also > possible I could create the Doxyfile as a .in file, and generate the > right OUTPUT_DIRECTORY for invocation through the buildsys. There's > actually an upstream example of exactly this: > > https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/14%20doxygen/doc/meson.build > > I'll look into options here. Figured this out, there's now a -Ddoxygen flag on the build system which will build and install the doxygen crap if wanted. Adding this requires a slight tweak on the autotools side to handle the Doxyfile -> Doxyfile.in rename and subsequent generation. dR
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Mon, Oct 22, 2018 at 11:16:25AM +1000, Allan McRae wrote: > On 22/10/18 10:03 am, Dave Reisner wrote: > > On Mon, Oct 22, 2018 at 09:56:04AM +1000, Allan McRae wrote: > >> On 22/10/18 8:57 am, Eli Schwartz wrote: > Also, most projects ship prebuilt man pages. I think some GNU ones > commit the built page to the tree, so that could be an option. > >> > >>> Both those things are also true about the configure and Makefile.in > >>> files... > >> > >> That is another good reason not to use git archive to create release > >> tarballs. > >> > >> A > > > > Consider that the reason we need 'make dist' and can't just use 'git > > archive' is because autotools *requires* extra tooling around just to > > generate the build system. This is no longer needed with meson. > > Good point! I'm not overly familiar with meson, so missed that completely. > > > Pre-generating the manpages means that our substitutions are > > invalidated. For example, someone building from the tarball with > > --prefix=/some/where/else or no --prefix at all will have a > > pacman.conf(5) that still claims the right path is /etc/pacman.conf > > > > I understand your point about python2 vs python3, but I think that's > > something we can work out based on a python3-based asciidoc in > > existance. > > Does the meson build script allow us to not create docs if wanted? Yes, see the meson_options.txt as part of this patch. One can invoke meson with -Ddoc=disabled to prevent manpages from being built. > > What problems here would you like to see solved for the inclusion of > > meson? That will help me focus my time spent on this. > > None need solved for inclusion in the current state. I'm just trying to > understand what our future release process will look like. Great! > While we have autotools in parallel, if I run "make dist" with this > patch, do all the needed meson files get included too? Can we get a > helper script to run doxygen? No, meson.build files will not be included with the autotools-built 'make dist' tarball. It feels weird to do this. I suspect that if we want to switch the Arch build over while this dual build-system world exists, we should just build from a tag in the git repo. Yes, I can add a script in build-aux to invoke doxygen. It's also possible I could create the Doxyfile as a .in file, and generate the right OUTPUT_DIRECTORY for invocation through the buildsys. There's actually an upstream example of exactly this: https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/14%20doxygen/doc/meson.build I'll look into options here. > Thanks, > Allan
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 10/21/18 9:32 PM, Eli Schwartz wrote: > On 10/21/18 9:16 PM, Allan McRae wrote: >> None need solved for inclusion in the current state. I'm just trying to >> understand what our future release process will look like. >> >> While we have autotools in parallel, if I run "make dist" with this >> patch, do all the needed meson files get included too? Can we get a >> helper script to run doxygen? > > No, I think this is entirely down to EXTRA_DIST in Makefile.am, but > specifying "meson_options.txt meson.build" might be enough. Nope, not only does this not include the new files in build-aux, autotools also only matches this file in the current directorya. So, time to hardcode a long list of files... -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 10/21/18 9:16 PM, Allan McRae wrote: > On 22/10/18 10:03 am, Dave Reisner wrote: >> On Mon, Oct 22, 2018 at 09:56:04AM +1000, Allan McRae wrote: >>> On 22/10/18 8:57 am, Eli Schwartz wrote: > Also, most projects ship prebuilt man pages. I think some GNU ones > commit the built page to the tree, so that could be an option. >>> Both those things are also true about the configure and Makefile.in files... >>> >>> That is another good reason not to use git archive to create release >>> tarballs. >>> >>> A >> >> Consider that the reason we need 'make dist' and can't just use 'git >> archive' is because autotools *requires* extra tooling around just to >> generate the build system. This is no longer needed with meson. > > Good point! I'm not overly familiar with meson, so missed that completely. > >> Pre-generating the manpages means that our substitutions are >> invalidated. For example, someone building from the tarball with >> --prefix=/some/where/else or no --prefix at all will have a >> pacman.conf(5) that still claims the right path is /etc/pacman.conf >> >> I understand your point about python2 vs python3, but I think that's >> something we can work out based on a python3-based asciidoc in >> existance. > > Does the meson build script allow us to not create docs if wanted? Yes, it does. The file meson_options.txt is used as a central location to list all options, their description, and default values -- which is nicely readable too, slightly unlike configure.ac. :) >> What problems here would you like to see solved for the inclusion of >> meson? That will help me focus my time spent on this. > > None need solved for inclusion in the current state. I'm just trying to > understand what our future release process will look like. > > While we have autotools in parallel, if I run "make dist" with this > patch, do all the needed meson files get included too? Can we get a > helper script to run doxygen? No, I think this is entirely down to EXTRA_DIST in Makefile.am, but specifying "meson_options.txt meson.build" might be enough. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 22/10/18 10:03 am, Dave Reisner wrote: > On Mon, Oct 22, 2018 at 09:56:04AM +1000, Allan McRae wrote: >> On 22/10/18 8:57 am, Eli Schwartz wrote: Also, most projects ship prebuilt man pages. I think some GNU ones commit the built page to the tree, so that could be an option. >> >>> Both those things are also true about the configure and Makefile.in files... >> >> That is another good reason not to use git archive to create release >> tarballs. >> >> A > > Consider that the reason we need 'make dist' and can't just use 'git > archive' is because autotools *requires* extra tooling around just to > generate the build system. This is no longer needed with meson. Good point! I'm not overly familiar with meson, so missed that completely. > Pre-generating the manpages means that our substitutions are > invalidated. For example, someone building from the tarball with > --prefix=/some/where/else or no --prefix at all will have a > pacman.conf(5) that still claims the right path is /etc/pacman.conf > > I understand your point about python2 vs python3, but I think that's > something we can work out based on a python3-based asciidoc in > existance. Does the meson build script allow us to not create docs if wanted? > What problems here would you like to see solved for the inclusion of > meson? That will help me focus my time spent on this. None need solved for inclusion in the current state. I'm just trying to understand what our future release process will look like. While we have autotools in parallel, if I run "make dist" with this patch, do all the needed meson files get included too? Can we get a helper script to run doxygen? Thanks, Allan
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 10/21/18 7:56 PM, Allan McRae wrote: > On 22/10/18 8:57 am, Eli Schwartz wrote: >>> Also, most projects ship prebuilt man pages. I think some GNU ones >>> commit the built page to the tree, so that could be an option. > >> Both those things are also true about the configure and Makefile.in files... > > That is another good reason not to use git archive to create release > tarballs. Well, the point I'm trying to make here is that they're connected. They ship prebuilt man pages because they're already forced into using make dist in order to generate the build system. The egregiously offensive ones even commit their autotools results to git which is pure madness... It's not pure madness to check manpages into git, but it also doesn't seem like a hugely important thing. Excepting projects that only provide troff-formatted manpages from the start, and autotools project where it doesn't prove anything, how many are left that provide pregenerated manpages? ... Anyway, given this patch is meant to provide an alternative to autotools, if we ever stop generating autotools dist tarballs it is because we don't need configure/Makefile.in anymore, in which case arguing based on that merit will be obsolete, and the only question to consider is the doc files specifically. For which we'll need to ask the question, did we ever need them in the first place or were we just used to having them as a byproduct of the previous build system requirements. I guess we have time to think about how to fully implement a dist target for meson, after getting it completed as a valid build target first... -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Mon, Oct 22, 2018 at 09:56:04AM +1000, Allan McRae wrote: > On 22/10/18 8:57 am, Eli Schwartz wrote: > >> Also, most projects ship prebuilt man pages. I think some GNU ones > >> commit the built page to the tree, so that could be an option. > > > Both those things are also true about the configure and Makefile.in files... > > That is another good reason not to use git archive to create release > tarballs. > > A Consider that the reason we need 'make dist' and can't just use 'git archive' is because autotools *requires* extra tooling around just to generate the build system. This is no longer needed with meson. Pre-generating the manpages means that our substitutions are invalidated. For example, someone building from the tarball with --prefix=/some/where/else or no --prefix at all will have a pacman.conf(5) that still claims the right path is /etc/pacman.conf I understand your point about python2 vs python3, but I think that's something we can work out based on a python3-based asciidoc in existance. What problems here would you like to see solved for the inclusion of meson? That will help me focus my time spent on this. dR
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 22/10/18 8:57 am, Eli Schwartz wrote: >> Also, most projects ship prebuilt man pages. I think some GNU ones >> commit the built page to the tree, so that could be an option. > Both those things are also true about the configure and Makefile.in files... That is another good reason not to use git archive to create release tarballs. A
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 22/10/18 8:12 am, Dave Reisner wrote: > On Mon, Oct 22, 2018 at 07:54:57AM +1000, Allan McRae wrote: >> On 22/10/18 7:46 am, Dave Reisner wrote: >>> 3) No 'make dist' equivalent. Just run 'git archive' to generate a >>> suitable tarball for distribution. >> >> Is there a way to include pregenerated man pages with git archive? >> >> A > > No, git archive only considers what's in the git tree. Is there a reason > we're determined to pre-generate the manpages instead of just adding > makedepends on ascididoc? > I think providing prebuilt man pages is more important now we require python3 for testing given asciidoc requires python2. Also, most projects ship prebuilt man pages. I think some GNU ones commit the built page to the tree, so that could be an option. Allan
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 10/21/18 6:12 PM, Dave Reisner wrote: > On Mon, Oct 22, 2018 at 07:54:57AM +1000, Allan McRae wrote: >> On 22/10/18 7:46 am, Dave Reisner wrote: >>> 3) No 'make dist' equivalent. Just run 'git archive' to generate a >>> suitable tarball for distribution. >> >> Is there a way to include pregenerated man pages with git archive? >> >> A > > No, git archive only considers what's in the git tree. Is there a reason > we're determined to pre-generate the manpages instead of just adding > makedepends on ascididoc? I've got a better question, shouldn't we explicitly want to generate them at build time? The output depends on buildtime options -- it uses pkgdatadir, localstatedir, sysconfdir, datarootdir to redefine paths in the manpages. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On Mon, Oct 22, 2018 at 07:54:57AM +1000, Allan McRae wrote: > On 22/10/18 7:46 am, Dave Reisner wrote: > > 3) No 'make dist' equivalent. Just run 'git archive' to generate a > > suitable tarball for distribution. > > Is there a way to include pregenerated man pages with git archive? > > A No, git archive only considers what's in the git tree. Is there a reason we're determined to pre-generate the manpages instead of just adding makedepends on ascididoc?
Re: [pacman-dev] [PATCH] Add meson.build files to build with meson
On 22/10/18 7:46 am, Dave Reisner wrote: > 3) No 'make dist' equivalent. Just run 'git archive' to generate a > suitable tarball for distribution. Is there a way to include pregenerated man pages with git archive? A
