On Mon, Aug 3, 2020 at 7:08 PM Orion Poplawski wrote:
>
> On 7/7/20 12:09 PM, Neal Gompa wrote:
> > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote:
> >>
> >> On 6/15/20 1:47 PM, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >>>
>
> >>> ==
On 7/7/20 12:09 PM, Neal Gompa wrote:
> On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote:
>>
>> On 6/15/20 1:47 PM, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>>>
>>> == Upgrade/compatibility impact ==
>>> Existing packages can (and most like
On Monday, 20 July 2020 at 21:39, Neal Gompa wrote:
> On Mon, Jul 20, 2020 at 3:32 PM Dominik 'Rathann' Mierzejewski
> wrote:
[...]
> > Sorry, but when you break other packagers workflows, the least you
> > can do is provide a clean solution to make them work again. Making a
> > change and telling
On Mon, Jul 20, 2020 at 3:32 PM Dominik 'Rathann' Mierzejewski
wrote:
>
> On Wednesday, 08 July 2020 at 15:19, Igor Raits wrote:
> > On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote:
> > > On 07.07.2020 19:57, Orion Poplawski wrote:
> > > > What's the plan for EPEL8/7 compatibilit
On Wednesday, 08 July 2020 at 15:19, Igor Raits wrote:
> On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote:
> > On 07.07.2020 19:57, Orion Poplawski wrote:
> > > What's the plan for EPEL8/7 compatibility?
> >
> > +1. The new Cmake macros behaviour must be backported to EPEL7/8.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote:
> On 07.07.2020 19:57, Orion Poplawski wrote:
> > What's the plan for EPEL8/7 compatibility?
>
> +1. The new Cmake macros behaviour must be backported to EPEL7/8.
Feel free to submi
On 07.07.2020 19:57, Orion Poplawski wrote:
> What's the plan for EPEL8/7 compatibility?
+1. The new Cmake macros behaviour must be backported to EPEL7/8.
Currently all fixed by proven packages SPEC files cannot be built on
EPEL branches.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
_
On Wed, Jul 8, 2020 at 4:11 AM Igor Raits
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote:
> > Richard Shaw 于 2020年7月8日周三 上午6:11写道：
> >
> > > Ok, so it appears this change was for F32+ only, so I can't merge
> > > master
> > > into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote:
> Richard Shaw 于 2020年7月8日周三 上午6:11写道：
>
> > Ok, so it appears this change was for F32+ only, so I can't merge
> > master
> > into f32 or earlier...
> >
> Maybe wait it to be backported into f31.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 11:57 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 12:07 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
Richard Shaw 于 2020年7月8日周三 上午6:11写道：
> Ok, so it appears this change was for F32+ only, so I can't merge master
> into f32 or earlier...
>
Maybe wait it to be backported into f31. The documents said this will be
backported into older supported version.
But now, merging master into older version
Ok, so it appears this change was for F32+ only, so I can't merge master
into f32 or earlier...
This whole change is still broken AF.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lis
On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote:
>
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B parameter)
> > to use separate build folder (already standardized
On 6/15/20 1:47 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%c
On 6/15/20 1:47 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%c
On Fri, Jul 3, 2020 at 3:44 PM Robert-André Mauchin wrote:
>
> On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> > Just wanted to provide some update on this change.
> >
> > * %__cmake_in_source_build macro has been introduced and set to 1. It
> > controls what arguments are passed to `cmak
On Friday, 3 July 2020 19:41:40 CEST Igor Raits wrote:
> Just wanted to provide some update on this change.
>
> * %__cmake_in_source_build macro has been introduced and set to 1. It
> controls what arguments are passed to `cmake -B ...`, `cmake --build
> ...`, `cmake --install ...` and in which di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Just wanted to provide some update on this change.
* %__cmake_in_source_build macro has been introduced and set to 1. It
controls what arguments are passed to `cmake -B ...`, `cmake --build
...`, `cmake --install ...` and in which directory `ctest`
Gary Buhrmaster wrote:
> On Wed, Jun 17, 2020 at 5:41 AM Igor Raits
> wrote:
>
>>
>> %if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
>>
>
> Yes, I have written such spec file lines, and while
> they are correct, they tend to be ugly to parse for
> humans.
Apparently als
On Tue, 16 Jun 2020 at 07:10, Igor Raits
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> > Ben Cotton wrote:
> > > == Summary ==
> > > %cmake macro will be adjusted (-B
> > > parameter)
> > > to use separate build folder (alr
On Wed, Jun 17, 2020 at 5:41 AM Igor Raits
wrote:
>
> %if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
>
Yes, I have written such spec file lines, and while
they are correct, they tend to be ugly to parse for
humans.
While I know it is personal preference, I tend to
prefe
On 6/17/20 8:41 AM, Igor Raits wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 01:38 +0200, Kevin Kofler wrote:
James Cassell wrote:
If you're doing this, might I suggest reversing the condition so
the new
way is in the "else" part, hence "default"?
The problem i
On Tuesday, 16 June 2020 03.41.09 WEST Neal Gompa wrote:
> 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 bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 23:45 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > You can also do "%cmake -B %{_vpath_builddir}" and that will work
> > on
> > old and new distro releases alike.
>
> Not on really old distros, because it requires CMake 3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 23:52 +0200, Kevin Kofler wrote:
> Dan Čermák wrote:
> > Or you use the new %cmake macro only in the f32, epel8 and master
> > branch and leave the other branches as they are?
>
> That requires maintaining the branches separate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 15:18 +0200, Kevin Kofler wrote:
> Igor Raits wrote:
> > The correct way of doing out-of-source builds is to use `cmake -S .
> > -B
> > builddir` and not cd/pushd and other things. Sadly we can't
> > implement
> > this enforceme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2020-06-17 at 01:38 +0200, Kevin Kofler wrote:
> James Cassell wrote:
> > If you're doing this, might I suggest reversing the condition so
> > the new
> > way is in the "else" part, hence "default"?
>
> The problem is that this results in a
James Cassell wrote:
> If you're doing this, might I suggest reversing the condition so the new
> way is in the "else" part, hence "default"?
The problem is that this results in a counterintuitive &&, as in:
%if 0%{?fedora} <= 32 && 0%{?rhel} <= 8
(by de Morgan's law, or if you want to analyze it
On Tue, Jun 16, 2020, at 9:16 AM, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake
> > popd
> >
> > It's four lines. We get to simplify it down to one line. Proposal
>
Dan Čermák wrote:
> Or you use the new %cmake macro only in the f32, epel8 and master
> branch and leave the other branches as they are?
That requires maintaining the branches separately and not fast-forwarding
them, but fast-forwarding is the most convenient way to maintain several
leaf package
Neal Gompa wrote:
> You can also do "%cmake -B %{_vpath_builddir}" and that will work on
> old and new distro releases alike.
Not on really old distros, because it requires CMake 3.13 (2018-11-20):
https://cgold.readthedocs.io/en/latest/glossary/-B.html
(The undocumented variant "%cmake -H. -B%{_
On Mon, Jun 15, 2020 at 1:49 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 18:54 +0200, Dan Čermák wrote:
> Kevin Kofler writes:
>
> > Michael Catanzaro wrote:
> > > Kevin, the goal is to *simply* these packages:
> > >
> > > mkdir -p %{_target_platform}
> > > pushd %{_target_platform}
> > > %cmake
On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton wrote:
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro).
While there is certainly no requirement for different
distributions to work the same, as I recal
Kevin Kofler writes:
> Michael Catanzaro wrote:
>> Kevin, the goal is to *simply* these packages:
>>
>> mkdir -p %{_target_platform}
>> pushd %{_target_platform}
>> %cmake
>> popd
>>
>> It's four lines. We get to simplify it down to one line. Proposal
>> owners are provenpackagers and say they
On Tue, Jun 16, 2020 at 9:17 AM Kevin Kofler wrote:
>
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake
> > popd
> >
> > It's four lines. We get to simplify it down to one line. Proposal
> >
Igor Raits wrote:
> The correct way of doing out-of-source builds is to use `cmake -S . -B
> builddir` and not cd/pushd and other things. Sadly we can't implement
> this enforcement without breaking packages that do `cd/pushd` but we
> will fix them.
The pushd approach has been working since forev
Michael Catanzaro wrote:
> Kevin, the goal is to *simply* these packages:
>
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake
> popd
>
> It's four lines. We get to simplify it down to one line. Proposal
> owners are provenpackagers and say they will try to fix affected
> packag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 08:37 -0400, Neal Gompa wrote:
> On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar
> wrote:
> >
> > On Tue, 16 Jun 2020 at 03:09, Neal Gompa
> > wrote:
> > >
> > > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler <
> > > kevin.kof...@c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 12:16 +0200, Kevin Kofler wrote:
> Igor Raits wrote:
> > Example above will stop working,
>
> So your change breaks hundreds of packages, exactly those that
> already do
> what you think is the right thing.
The correct way of
On Tue, Jun 16, 2020 at 12:16 pm, Kevin Kofler
wrote:
So your change breaks hundreds of packages, exactly those that
already do
what you think is the right thing.
Hence, sorry, but I am opposed to this change.
Kevin, the goal is to *simply* these packages:
mkdir -p %{_target_platform}
pushd
On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar wrote:
>
> On Tue, 16 Jun 2020 at 03:09, Neal Gompa wrote:
> >
> > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler wrote:
> > >
> > > How does this affect the many packages that already build in a separate
> > > build folder manually? There are even severa
On Tuesday, June 16, 2020 12:18:29 PM CEST Kevin Kofler wrote:
> Igor Raits wrote:
>
> > Not sure if I follow, what means "can already be done with the existing
> > one"? Does it mean that you can already specify a build dir via CLI and
> > some packages already do (e.g. libsolv)?
>
>
> As I wro
On Tue, 16 Jun 2020 at 03:09, Neal Gompa wrote:
>
> On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler wrote:
> >
> > How does this affect the many packages that already build in a separate
> > build folder manually? There are even several specfile templates that
> > contain the boilerplate for that.
>
Igor Raits wrote:
> Not sure if I follow, what means "can already be done with the existing
> one"? Does it mean that you can already specify a build dir via CLI and
> some packages already do (e.g. libsolv)?
As I wrote elsewhere in the thread, most packages actually do the opposite
(which AFAIK
Igor Raits wrote:
> Example above will stop working,
So your change breaks hundreds of packages, exactly those that already do
what you think is the right thing.
Hence, sorry, but I am opposed to this change.
> but we definitely do not want to have build tree in
> x86_64-redhat-linux-gnu/x86_64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> >
On Mon, Jun 15, 2020 at 10:25 PM Kevin Kofler 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 a
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
On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler wrote:
>
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro wil
Ben Cotton wrote:
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the older
> supported Fedora releases
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%ctest macro will be created (and backport
55 matches
Mail list logo
