Hi,
during last FPC meeting we agreed[0] that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for: 1) source directory where CMakeLists.txt/meson.build/configure are 2) build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Ideas, suggestions are appreciated!
[0] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-13/fpc.2016-10-13... [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/cmake /cmake.macros?expand=1
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0] that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make),
For make and ninja-build, what works depends on the recipes. I don't think there are ways to tell in an automated way if out-of-tree builds are supported or not.
(There are also out-of-tree builds which still write to the source tree.)
Florian
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0]
Well, it was not agreed. Actually, I quit the meeting in protest against your plan and your lack of understanding.
that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
For decades, this is has been called VPATH-builds in make terms.
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for:
- source directory where CMakeLists.txt/meson.build/configure are
- build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
I don't see any need to do so nor has there been any demand for such beasts ever since rpm exists.
$(PWD), pushd/popd, sub-shelling are common means to avoid these.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Yes, SUSE always has a long history in cluttering their specs with useless macros and questionable features.
Ideas, suggestions are appreciated!
IMO, just drop this idea. It's featuritis.
On Mon, Oct 17, 2016 at 7:13 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0]
Well, it was not agreed. Actually, I quit the meeting in protest against your plan and your lack of understanding.
that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
For decades, this is has been called VPATH-builds in make terms.
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for:
- source directory where CMakeLists.txt/meson.build/configure are
- build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
I don't see any need to do so nor has there been any demand for such beasts ever since rpm exists.
$(PWD), pushd/popd, sub-shelling are common means to avoid these.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Yes, SUSE always has a long history in cluttering their specs with useless macros and questionable features.
Ideas, suggestions are appreciated!
IMO, just drop this idea. It's featuritis.
Problem is that with meson everyone will need to put this boilerplate stuff in *each* spec.
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On Monday, October 17, 2016 8:55:27 PM CEST Igor Gnatenko wrote:
On Mon, Oct 17, 2016 at 7:13 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0]
Well, it was not agreed. Actually, I quit the meeting in protest against your plan and your lack of understanding.
that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
For decades, this is has been called VPATH-builds in make terms.
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for:
- source directory where CMakeLists.txt/meson.build/configure are
- build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
I don't see any need to do so nor has there been any demand for such beasts ever since rpm exists.
$(PWD), pushd/popd, sub-shelling are common means to avoid these.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Yes, SUSE always has a long history in cluttering their specs with useless macros and questionable features.
Ideas, suggestions are appreciated!
IMO, just drop this idea. It's featuritis.
Pavel
Problem is that with meson everyone will need to put this boilerplate stuff in *each* spec.
Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages?
Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ...
Pavel
On Tue, Oct 18, 2016 at 10:44 AM, Pavel Raiskup praiskup@redhat.com wrote:
On Monday, October 17, 2016 8:55:27 PM CEST Igor Gnatenko wrote:
On Mon, Oct 17, 2016 at 7:13 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 10/17/2016 04:37 PM, Igor Gnatenko wrote:
Hi,
during last FPC meeting we agreed[0]
Well, it was not agreed. Actually, I quit the meeting in protest against your plan and your lack of understanding.
that we need some standardization of macro related to builds where builddir != srcdir (and with possibility to make it builddir = srcdir).
For decades, this is has been called VPATH-builds in make terms.
I was working to make guidelines for ninja and meson. For ninja it doesn't matter from where you build (it's like make), but meson itself accepts ONLY out-of-tree builds. Would be nice to get system-wide (rpm-wide?) macro which stands for:
- source directory where CMakeLists.txt/meson.build/configure are
- build directory (I think _target_platform is a good candidate)
to make out-of-tree conversion to in-tree, you do the RPM variable override.
I don't see any need to do so nor has there been any demand for such beasts ever since rpm exists.
$(PWD), pushd/popd, sub-shelling are common means to avoid these.
For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.
Yes, SUSE always has a long history in cluttering their specs with useless macros and questionable features.
Ideas, suggestions are appreciated!
IMO, just drop this idea. It's featuritis.
Pavel
Problem is that with meson everyone will need to put this boilerplate stuff in *each* spec.
Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages?
Actually it's related for any buildsystem with supports (or even requires out-of-tree building).
Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ...
mkdir build pushd build %meson .. popd %ninja_build -C build %ninja_install -C build
instead of this I would prefer to have %meson %meson_build %meson_install
In case of angelscript it's: mkdir build pushd build %meson ../sdk/angelscript/projects/meson/ popd %ninja_build -C build %ninja_install -C build
With some macro it would be just %global __srcdir sdk/angelscript/projects/meson %meson %meson_build %meson_install
but this applies for other buildsystems. For example, currently with CMake almost everyone does mkdir %{_target_platform} pushd %{_target_platform} %cmake .. popd %make_build -C %{_target_platform} %make_install -C %{_target_platform}
Pavel
On Tuesday, October 18, 2016 11:24:02 AM CEST Igor Gnatenko wrote:
Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages?
Actually it's related for any buildsystem with supports (or even requires out-of-tree building).
Hms, I'm not sure... Autotooled projects have VPATH builds (info automake) usually optional, and it usually requires maintainer uses `make distcheck` at least during release time (otherwise VPATH build likely get broken with time). I don't see much benefits in changing something which works now, or risk something..
Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ...
mkdir build pushd build %meson ..
The '..' is parent dir here I bet...
popd %ninja_build -C build %ninja_install -C build
... TBH, I don't see a big issues here. :) Can can simplify this by:
mkdir build pushd build %meson .. %ninja_build %ninja_install popd
?
instead of this I would prefer to have %meson %meson_build %meson_install
But, yes this sounds cool.
In case of angelscript it's: mkdir build pushd build %meson ../sdk/angelscript/projects/meson/ popd %ninja_build -C build %ninja_install -C build
With some macro it would be just %global __srcdir sdk/angelscript/projects/meson
Without knowing background peculiarities, this sounds wrong to me. Can we have this named like %meson_srcdir? From the "namespace" reasons ..
Or at least %vpath_builddir? So particular language specific macros could take %vpath_builddir in future? %__srcdir does not say what it is used for.
%meson %meson_build %meson_install
Though I'm not sure you need to have the %__srcdir at all. Can't you have parametrized %meson_vpath macro instead of %mason (so you say where build directory actually is)?
but this applies for other buildsystems. For example, currently with CMake almost everyone does mkdir %{_target_platform} pushd %{_target_platform} %cmake .. popd %make_build -C %{_target_platform} %make_install -C %{_target_platform}
Similarly here, if there was %vpath_builddir, %cmake could have been hacked to support that.
Pavel
On Tue, Oct 18, 2016 at 12:24 PM, Pavel Raiskup praiskup@redhat.com wrote:
On Tuesday, October 18, 2016 11:24:02 AM CEST Igor Gnatenko wrote:
Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages?
Actually it's related for any buildsystem with supports (or even requires out-of-tree building).
Hms, I'm not sure... Autotooled projects have VPATH builds (info automake) usually optional, and it usually requires maintainer uses `make distcheck` at least during release time (otherwise VPATH build likely get broken with time). I don't see much benefits in changing something which works now, or risk something..
mostly I'm talking here about cmake and meson (and probably gyp in future).
Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ...
mkdir build pushd build %meson ..
The '..' is parent dir here I bet...
yes
popd %ninja_build -C build %ninja_install -C build
... TBH, I don't see a big issues here. :) Can can simplify this by:
mkdir build pushd build %meson .. %ninja_build %ninja_install popd?
%ninja_install should go under %install, so you have to add pushd once more there.
instead of this I would prefer to have %meson %meson_build %meson_install
But, yes this sounds cool.
In case of angelscript it's: mkdir build pushd build %meson ../sdk/angelscript/projects/meson/ popd %ninja_build -C build %ninja_install -C build
With some macro it would be just %global __srcdir sdk/angelscript/projects/meson
Without knowing background peculiarities, this sounds wrong to me. Can we have this named like %meson_srcdir? From the "namespace" reasons ..
as I said, it's general thing for buildsystems. Not always you have CMakeListst.txt under the root directory (usually yes, but there are exceptions).
Or at least %vpath_builddir? So particular language specific macros could take %vpath_builddir in future? %__srcdir does not say what it is used for.
%__srcdir: I wrote it somewhere. It stands for directory with CMakeLists.txt/configure/meson.build/etc.
I think %vpath_srcdir and %vpath_builddir are good names.
%meson %meson_build %meson_install
Though I'm not sure you need to have the %__srcdir at all. Can't you have parametrized %meson_vpath macro instead of %mason (so you say where build directory actually is)?
it's just complicating things. Almost no one will override %vpath_srcdir.
but this applies for other buildsystems. For example, currently with CMake almost everyone does mkdir %{_target_platform} pushd %{_target_platform} %cmake .. popd %make_build -C %{_target_platform} %make_install -C %{_target_platform}
Similarly here, if there was %vpath_builddir, %cmake could have been hacked to support that.
Here comes question, where %vpath_srcdir and %vpath_builddir should be defined? I would prefer to see it somewhere in RPM, so other distros can use it as well. But I can agree on redhat-rpm-macro or any other packages.
Pavel
On Tuesday, October 18, 2016 1:10:35 PM CEST Igor Gnatenko wrote:
Similarly here, if there was %vpath_builddir, %cmake could have been hacked to support that.
Here comes question, where %vpath_srcdir and %vpath_builddir should be defined? I would prefer to see it somewhere in RPM, so other distros can use it as well. But I can agree on redhat-rpm-macro or any other packages.
I was about to believe that by default we could have those undefined, so we'll be sure that we'll clearly see that we don't chagne regular package builds. ... only those who explicitly opt-in this will be affected.
Thanks, Pavel
On Tue, Oct 18, 2016 at 1:16 PM, Pavel Raiskup praiskup@redhat.com wrote:
On Tuesday, October 18, 2016 1:10:35 PM CEST Igor Gnatenko wrote:
Similarly here, if there was %vpath_builddir, %cmake could have been hacked to support that.
Here comes question, where %vpath_srcdir and %vpath_builddir should be defined? I would prefer to see it somewhere in RPM, so other distros can use it as well. But I can agree on redhat-rpm-macro or any other packages.
I was about to believe that by default we could have those undefined, so we'll be sure that we'll clearly see that we don't chagne regular package builds. ... only those who explicitly opt-in this will be affected.
For meson, gyp and some other buildsystems there are no opt-in neither opt-out. It just doesn't work other way, only VPATH build. So my idea was to define those somewhere in RPM and meson/gyp/etc. will use it, others (like cmake) can use it in opt-in model.
For CMake I don't think we can/will do anything related to this right now. In the future we can define %cmake_vpath.
Thanks, Pavel
On 10/18/2016 01:24 PM, Pavel Raiskup wrote:
On Tuesday, October 18, 2016 11:24:02 AM CEST Igor Gnatenko wrote:
Is this strictly %meson related? Could the generalizing be done in `redhat-rpm-macros` within %meson_ namespace so we can avoid touching all packages?
Actually it's related for any buildsystem with supports (or even requires out-of-tree building).
Hms, I'm not sure... Autotooled projects have VPATH builds (info automake) usually optional, and it usually requires maintainer uses `make distcheck` at least during release time (otherwise VPATH build likely get broken with time). I don't see much benefits in changing something which works now, or risk something..
Though I'm not aware of the actual PoC, neither what boilerplate typing needs to be done for every %meson package, probably worth sharing ...
mkdir build pushd build %meson ..
The '..' is parent dir here I bet...
popd %ninja_build -C build %ninja_install -C build
... TBH, I don't see a big issues here. :) Can can simplify this by:
mkdir build pushd build %meson .. %ninja_build %ninja_install popd?
instead of this I would prefer to have %meson %meson_build %meson_install
But, yes this sounds cool.
Yes. FWIW this is just the kind of direction I'd like to see everything using a common build infra (be it cmake, autotools, python/ruby/whatever etc) evolve towards.
In case of angelscript it's: mkdir build pushd build %meson ../sdk/angelscript/projects/meson/ popd %ninja_build -C build %ninja_install -C build
With some macro it would be just %global __srcdir sdk/angelscript/projects/meson
Without knowing background peculiarities, this sounds wrong to me. Can we have this named like %meson_srcdir? From the "namespace" reasons ..
Or at least %vpath_builddir? So particular language specific macros could take %vpath_builddir in future? %__srcdir does not say what it is used for.
%meson %meson_build %meson_install
Though I'm not sure you need to have the %__srcdir at all. Can't you have parametrized %meson_vpath macro instead of %mason (so you say where build directory actually is)?
but this applies for other buildsystems. For example, currently with CMake almost everyone does mkdir %{_target_platform} pushd %{_target_platform} %cmake .. popd %make_build -C %{_target_platform} %make_install -C %{_target_platform}
Similarly here, if there was %vpath_builddir, %cmake could have been hacked to support that.
If (almost) everybody is repeating these steps then why are they not macroized into something like %cmake_setup, %cmake_build and %cmake_install? Okay, it requires somebody to actually do it and sanction but...
Taking the idea a bit further, if everything were to follow such %foo_setup, %foo_build, %foo_install then at least in simple and/or well-behaved cases you could do the whole setup-build-install thing with one spec line wher just the type varies:
%autobuild foo
/me wakes up and lets the cat out...
- Panu -
Pavel _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
On Tuesday, 18 October 2016 at 13:28, Panu Matilainen wrote: [...]
If (almost) everybody is repeating these steps then why are they not macroized into something like %cmake_setup, %cmake_build and %cmake_install? Okay, it requires somebody to actually do it and sanction but...
Taking the idea a bit further, if everything were to follow such %foo_setup, %foo_build, %foo_install then at least in simple and/or well-behaved cases you could do the whole setup-build-install thing with one spec line wher just the type varies:
%autobuild foo
Now *that* is a really cool idea.
Regards, Dominik
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> macroized into something like %cmake_setup, %cmake_build and PM> %cmake_install? Okay, it requires somebody to actually do it and PM> sanction but...
Well, I try but to be honest I thought cmake was fairly cleaned up. And yes, I agree that to as much of a degree as possible, the macros for various buildsystems should follow a basic %configure/%make_build/%make_install pattern.
PM> Taking the idea a bit further, if everything were to follow such PM> %foo_setup, %foo_build, %foo_install then at least in simple and/or PM> well-behaved cases you could do the whole setup-build-install thing PM> with one spec line wher just the type varies:
PM> %autobuild foo
Now look here. Usually I'm the one who proposes things like this, and usually everyone tells me I'm insane and that the RPM people would never go for it. And sometimes I do actually try implementing those things, where I generally run into some minor thing that RPM proper would need to add, but indeed the RPM folks aren't interested. Probably because I'm not providing the needed patch to RPM, whose code simply hurts my brain.
But if Panu's going to propose crazy things, too, then I'm going to consider that ample justification and drag out some of those old ideas I have stashed away.
But back to reality, I wish there were enough packages which actually worked without needing to tweak something or pass extra flags or change some permissions at the end of install or whatever to make this actually something which would be generally useful. Because even if the super simple thing works at some point in time, upstream is eventually going to put out an update that requires you to tweak something, and then you'd have to delete your pretty autobuild call and do back to the old school way of doing things.
Now if RPM let you have multiple %build or %install sections and just concatenated them, then you could have %autobuild and then later an %install section that removes that stuff you didn't want installed or does that recursive permission change..... But it doesn't.
On 10/18/2016 10:50 PM, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> macroized into something like %cmake_setup, %cmake_build and PM> %cmake_install? Okay, it requires somebody to actually do it and PM> sanction but...
Well, I try but to be honest I thought cmake was fairly cleaned up. And yes, I agree that to as much of a degree as possible, the macros for various buildsystems should follow a basic %configure/%make_build/%make_install pattern.
Oh, I wasn't picking on you, sorry if it came out like that. I don't really know what all these build systems are, much less what their "completeness" is :)
PM> Taking the idea a bit further, if everything were to follow such PM> %foo_setup, %foo_build, %foo_install then at least in simple and/or PM> well-behaved cases you could do the whole setup-build-install thing PM> with one spec line wher just the type varies:
PM> %autobuild foo
Now look here. Usually I'm the one who proposes things like this, and usually everyone tells me I'm insane and that the RPM people would never go for it. And sometimes I do actually try implementing those things, where I generally run into some minor thing that RPM proper would need to add, but indeed the RPM folks aren't interested. Probably because I'm not providing the needed patch to RPM, whose code simply hurts my brain.
But if Panu's going to propose crazy things, too, then I'm going to consider that ample justification and drag out some of those old ideas I have stashed away.
I don't know what's so crazy about this.
But back to reality, I wish there were enough packages which actually worked without needing to tweak something or pass extra flags or change some permissions at the end of install or whatever to make this actually something which would be generally useful. Because even if the super simple thing works at some point in time, upstream is eventually going to put out an update that requires you to tweak something, and then you'd have to delete your pretty autobuild call and do back to the old school way of doing things.
Yes, ability to selectively override and/or pick suitable pieces is absolutely vital. If its just the magic oneline or everything manual and nothing in between its just worthless.
Now if RPM let you have multiple %build or %install sections and just concatenated them, then you could have %autobuild and then later an %install section that removes that stuff you didn't want installed or does that recursive permission change..... But it doesn't.
Multiple %build/%install might be one possible way but by no means the only one.
For example rpm could automatically create default %build and %install sections (like it does for %clean) from a template, and then if something in the automation doesn't work you can override just the part that doesn't work. And any such template would (have to) have pre, post etc sections you can override/fill up.
Macros can go a long way but something like this would almost certainly benefit from having some level of knowledge within rpm itself. In rather broad strokes so to speak, invoking the automation could be something like:
ProjectType: cmake
That would (try to) populate default %build and %install from cmake template, assuming such a thing exists, and in the simple case that'd be all you need.
To tweak something in, say, %install, you'd then override that, invoke the template macro manually and do your stuff around it as necessary, eg:
--- %install %cmake_install_template
# upstream makefile leaves junk around rm -rf %{buildroot}/... ---
Mind you, I haven't thought about the actual details here too much so I'm sure there are pitfalls and everything, but something like this should not be hard at all on rpm side.
- Panu -
- Panu -
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Florian Weimer -
Igor Gnatenko -
Jason L Tibbitts III -
Panu Matilainen -
Pavel Raiskup -
Ralf Corsepius