Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Closed #2886. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#event-11754968569 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Okay this PR served its purpose, lessons learned: not this way, and not just now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1935490089 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
> And, -s points at the source directory when it's the build directory you'd
> like to be able to name, so it's quite backwards.
Oh, now I see. The patch actually works the opposite way then I anticipated. It
actually introduces `%{sourcesubdir}` while the `%{buildsubdir}` is actually
already existing and is the current directory for `%configure` but also `%make`
call, as it always was. This also explains the quote bellow, why you don't see
need to change the make macros.
> > BTW this does not update the `make` macros, right? Which are likely more
> > noisy then the `configure` itself. IOW on one `./configure` call, there are
> > typically two make calls, such as `make` and `make install`
>
> There's nothing to update wrt the make macros. configure, which exists in the
> _soure_ directory, generates the makefiles into the build directory, and then
> you just run make as you always did. Noisiness has nothing to do with it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1929658172
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
> I am not sure if tying this to the `%setup` is useful, unless there is also
> some alternative to setup this independently. Maybe if the `%{-s}` also
> accepted some alternative build name(s).
The way builds are tied to %setup, I think there needs to be a way to achieve
this via %setup. It shouldn't be *tied* to %setup though. Having slept over it,
the approach in this draft doesn't cut it though. We want something that is an
opt-in for existing specs, yet something that can be made a default in
buildsystem macros with an opt-out for the occasionally buggy package. The -s
flag does not work for that. And, -s points at the source directory when it's
the *build* directory you'd like to be able to name, so it's quite backwards.
> > A one gotcha here is that special %doc and %license has traditionally
> > worked for both built and pre-existing content.
>
> The files could be gathered in `%{sourcesubdir}` followed by
> `%{buildsubdir}`, why not. But how often is the documentation build? It never
> came to my mind that the documentation could be generated during build and I
> wouldn't mind if only the former was possible. Or actually if neither one
> worked and the documentation would need to be installed into
> `%{_buildrootdir}` manually.
Building docs isn't uncommon at all, but whether the result gets included via
special %doc (as opposed to installing) is another question. It's a case we've
had in rpm itself too.
>
> BTW this does not update the `make` macros, right? Which are likely more
> noisy then the `configure` itself. IOW on one `./configure` call, there are
> typically two make calls, such as `make` and `make install`
There's nothing to update wrt the make macros. configure generates the
makefiles into the build directory, and then you just run make as you always
did.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1929002514
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
I am not sure if tying this to the `%setup` is useful, unless there is also
some alternative to setup this independently. Maybe if the `%{-s}` also
accepted some alternative build name(s).
> A one gotcha here is that special %doc and %license has traditionally worked
> for both built and pre-existing content.
The files could be gathered in `%{sourcesubdir}` followed by `%{buildsubdir}`,
why not. But how often is the documentation build? It never came to my mind
that the documentation could be generated during build and I wouldn't mind if
only the former was possible. Or actually if neither one worked and the
documentation would need to be installed into `%{_buildrootdir}` manually.
BTW this does not update the `make` macros, right? Which are likely more noisy
then the `configure` itself. IOW on one `./configure` call, there are typically
two make calls, such as `make` and `make install`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1927267885
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Besides PoC, this is of course rather simple-minded too. There may be some interesting possibilities in supporting multiple build variants natively here. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926707782 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
This is on top of the per-build directory PR because it makes this much easier to do, ie the actual feature here is just the last commit. This is NOT meant for merging at this point, just that even a crude implementation is easier to discuss than thin air. See also https://github.com/rpm-software-management/rpm/discussions/2882 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2886#issuecomment-1926674899 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Proof-of-concept native support for vpath-style builds (PR #2886)
Add a new %setup switch -s to indicate building in a directory outside the
source directory, known as vpath build in some circles. Add a new
%{sourcesubdir} macro which by default equals %{buildsubdir}, but when -s is
used, we create and switch to a separate directory after unpacking.
A one gotcha here is that special %doc and %license has traditionally worked
for both built and pre-existing content. With build and source trees separated,
both cannot work. As special %doc/%license is mostly used for things like
READMEs and COPYING which come as part of the source, we define %doc on
vpath builds to mean source directory, and assume built content has its own
means of installing (eg make install-doc).
Another potential issue is that we redefine %_configure to an absolute path in
the sourcesubdir, this would break some unusual cases where %configure is used
to invoke a configure-script outside the project top directory. Its mainly
redefined here to make testing -s on an autotools project easy, a final
implementation might do something else.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2886
-- Commit Summary --
* Introduce an rpm-controlled per-build directory
* Make buildroot fully rpm controlled, always inside the per-build directory
* Move SPECPARTS to per-pkg builddir, no longer needing name-version
* PoC: Add native support for vpath-style builds outside the source tree
-- File Changes --
M build/build.c (38)
M build/files.c (2)
M build/parsePreamble.c (30)
M build/parsePrep.c (20)
M build/parseSpec.c (15)
M build/rpmbuild_internal.h (1)
M build/spec.c (4)
M include/rpm/rpmbuild.h (3)
M macros.in (22)
M tests/rpmbuild.at (46)
M tests/rpmspec.at (8)
M tools/rpmbuild.c (18)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/2886.patch
https://github.com/rpm-software-management/rpm/pull/2886.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886
You are receiving this because you are subscribed to this thread.
Message ID: rpm-software-management/rpm/pull/2...@github.com
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
