@pmatilai commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
Thanks for finally landing this!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1892038147
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2774 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#event-11487059342
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Okay I guess we've had all the feedback we're going to get on this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1891987087
You are receiving this because you are subscribed to this thread.
Message ID:
The last commit to not ship our example buildsystem macros could/should be
merged into the "Implement..." commit instead, just made it separate to make it
easy to back out if necessary.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 5 commits.
6805bd7fded2d83369d9317c7fdeb1063f2d1af4 Use rpmSpecGetSection() internally
where appropriate
40c0721f8055378bdc3461b155c97438945bc498 Store spec section string buffers as
an array
ddb1c4bdf23ab1074049d827990170074e02901f Implement declarative buildsystem
support
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1815228582
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 1 commit.
c4be21841fbdde56f647247758f54e31eb99fc31 Define a global %clean default, reuse
for the non-buildsystem, case too
--
View it on GitHub:
@dmnks commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
Oh. Any resemblance to Flatpak is purely coincidental, I swear :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883072742
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
Also, bonus points for being (perhaps accidentally) consistent with Flapak's
naming (`BuildSystem` vs `buildsystem`):
https://github.com/flathub/io.gitlab.osslugaru.Lugaru/blob/5580684b5524ddd63d289bbc06cc0305eae189b5/io.gitlab.osslugaru.Lugaru.json#L21
--
Reply to this email directly or view
@dmnks commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
@dmnks commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
@dmnks commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
> I personally hate whenever I need to look up the correct syntax for line
> breaks in a config format
OK, maybe this point is moot since I guess the line break syntax really is
actually the SPEC's native one... but you get the point :smile:
--
Reply to this email directly or view it on
I'm a bit late to the :tada: but as far as the overall solution, I'm giving the
tag-based variant (`BuildSystem:`) implemented here a :+1: . I'm also giving a
:+1: to the shorter Build* namespace (the Auto prefix really had to go :smile:).
It looks to me like the cleanest and most flexible
Oops, there was an unrelated extra commit from work related to #2803, must've
gotten my local branches mixed up...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1876881461
You are receiving this because you are
Added docs for the global defaults + some other tweaks in that department, and
added a cmake buildsystem example.
I think this is ready to go now. As with any new feature there's likely to be
some rough edges, but those are best found in hands of the users rather than
sitting in a draft
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
Documented in the last push.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> +%buildsystem_python_build
+```
+
+## Supporting new build systems
+
+Supporting new build system types is just a matter of declaring a few
+macros for the build scriptlet sections relevant to the build system.
+
+Scriptlet | Mandatory
@pmatilai pushed 4 commits.
03dfaa56dd67073cbbe27fd125167bc79acda55c Extract static tests for easier
release bumps
a939bee8957e01ba8ece72c16727909f94d138fb Use rpmSpecGetSection() internally
where appropriate
159a96eff15edd4defb52399b22f7edaffbfb354 Store spec section string buffers as
an
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
Oh, another point regarding this: this will allow declaratively changing %prep
behavior too, eg `BuildOption(prep): -n %{name}`. That wont
@pmatilai commented on this pull request.
> +%buildsystem_python_build
+```
+
+## Supporting new build systems
+
+Supporting new build system types is just a matter of declaring a few
+macros for the build scriptlet sections relevant to the build system.
+
+Scriptlet | Mandatory
@Conan-Kudo requested changes on this pull request.
> +%buildsystem_python_build
+```
+
+## Supporting new build systems
+
+Supporting new build system types is just a matter of declaring a few
+macros for the build scriptlet sections relevant to the build system.
+
+Scriptlet |
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
+
+# example buildsystem macros for autotools
Ack. At any rate, a PR like this needs to have *something* for demonstration
purposes, and
@voxik commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
+
+# example buildsystem macros for autotools
I just wanted to open the question, because I am maintaining mainly rubygem-*
packages where
At least for now, these are just macros that can be defined anywhere. But I do
fail to see the point of a spec defined buildsystem.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1822232591
You are receiving this
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
+
+# example buildsystem macros for autotools
"Defaults" seems ambiguous in this context of %buildsystem_default_*. But
assuming you mean
@pmatilai commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
Right, I'll need to document it. %buildsystem_default_* is just something a
spec using Buildsystem: will fall back to if the buildsystem
> And in relation to #782, is it possible to define the 'buildsystem' inside of
> the .spec file?
Although admittedly, not sure what would be the utility 樂
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1821076512
You
And in relation to #782, is it possible to define the 'buildsystem' inside of
the .spec file?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1821074359
You are receiving this because you are subscribed to this thread.
@voxik commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
+
+# example buildsystem macros for autotools
Is autotools really so prominent to be part of defaults?
--
Reply to this email directly or view
@voxik commented on this pull request.
> @@ -1352,5 +1352,16 @@ end
end
}
+# buildsystem defaults
+%buildsystem_default_prep() %autosetup -p1
I don't see this to be documented. Is it something one should use for something?
--
Reply to this email directly or view it on GitHub:
Building on the feedback from the #2620 draft, this seems more like it. Now
even with documentation :smile:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2774
-- Commit Summary --
* Add support for retrieving
35 matches
Mail list logo
