On Mon, Jun 15, 2020 at 10:25 PM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Neal Gompa wrote:
> If they build a separate folder manually and are already using the
> VPATH macros, then there's no change. If they're using a different
> structure, we can adapt them to the standard VPATH macros, and do
> other adjustments as needed.
The common idiom in KDE packages is:
mkdir %{_target_platform}
pushd %{_target_platform}
%{cmake_kf5} ..
popd
So:
1. Are you going to apply this change also to %{cmake_kf5} or just plain
%cmake?
Yeah, this will get applied to %cmake_kf5 as well.
2. If a construct like this is used, I guess we will end up with a
VPATH
inside %{_target_platform}? So the -debugsource package will have a
nested structure like Russian matrioshka puppets or Chinese boxes?
%_vpath_builddir already is set to %_target_platform, so we'd just
swap one for the other.
> Defaults matter. And upstreams complain about us not doing out
of tree
> builds by default. Some projects even intentionally break in-source
> builds and packagers shouldn't struggle to figure out how to do the
> right thing in that circumstance.
It is unfortunate that some upstreams (including parts of KDE) are doing
this. This is a very pointless and unhelpful thing to do. I see no benefit
from disallowing in-source builds, it is just a simple special case and
normally requires no extra code to support.
CMake themselves do not recommend doing in-source builds (and they've
already warned that this will eventually stop working). Meson doesn't
even permit it. These days, Autotools is the weird exception that
mostly mandates in-source builds.
--
真実はいつも一つ!/ Always, there's only one truth!