> 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-software-management/rpm/pull/2886/c1929002...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to