On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11) with cmake-3.18.0-1.fc33 and the build(s) were successful.
Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake- 3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with:
...
+ make -j5 make: *** No targets specified and no makefile found. Stop.
see, e.g., https://koji.fedoraproject.org/koji/watchlogs?taskID=47508501
No changes to the .spec other than Release and %changelog.
Anyone else seeing this?
--
Kaleb
On Mon, Jul 20, 2020 at 1:29 PM Kaleb Keithley kkeithle@redhat.com wrote:
On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11) with cmake-3.18.0-1.fc33 and the build(s) were successful.
Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake- 3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with:
...
- make -j5
make: *** No targets specified and no makefile found. Stop.
see, e.g., https://koji.fedoraproject.org/koji/watchlogs?taskID=47508501
No changes to the .spec other than Release and %changelog.
Anyone else seeing this?
This is because ceph is not adapted yet for https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
Your spec file is a complete mess, so I have not yet touched it to fix it.
Here's an example of how I fixed one package: https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576...
On Monday, July 20, 2020 7:37:25 PM CEST Neal Gompa wrote:
This is because ceph is not adapted yet for https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
Yes, this change broke a lot of builds as it had been discussed on this list.
Your spec file is a complete mess, so I have not yet touched it to fix it.
The spec file looks fine to me. Have you ever seen texlive.spec?
Here's an example of how I fixed one package: https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576 6cba54da78
I had exactly the same problem in my own projects. Appending -B. at the end of the line(s) starting with %cmake has fixed it:
https://github.com/kdudka/predator/commit/34ef2198
Kamil
On Mon, Jul 20, 2020 at 2:31 PM Kamil Dudka kdudka@redhat.com wrote:
On Monday, July 20, 2020 7:37:25 PM CEST Neal Gompa wrote:
This is because ceph is not adapted yet for https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
Yes, this change broke a lot of builds as it had been discussed on this list.
Your spec file is a complete mess, so I have not yet touched it to fix it.
The spec file looks fine to me. Have you ever seen texlive.spec?
Yes, I have. It's *evil*. It also doesn't use CMake. It's irrelevant in the context of this change.
Here's an example of how I fixed one package: https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576 6cba54da78
I had exactly the same problem in my own projects. Appending -B. at the end of the line(s) starting with %cmake has fixed it:
Or you could just use "%global __cmake_in_source_build 1" which reverts to the previous behavior.
Or you could *actually* make it do it out of source even with older Fedora releases as I did with my example commit.
On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
Or you could just use "%global __cmake_in_source_build 1" which reverts to the previous behavior.
That does not make any sense. The packages I talk about have used out of source builds since forever.
Or you could *actually* make it do it out of source even with older Fedora releases as I did with my example commit.
I thought I did. And not only for Fedora releases ;-)
https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/
Kamil
On Monday, 20 July 2020 at 20:46, Kamil Dudka wrote:
On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
Or you could just use "%global __cmake_in_source_build 1" which reverts to the previous behavior.
That does not make any sense. The packages I talk about have used out of source builds since forever.
Or you could *actually* make it do it out of source even with older Fedora releases as I did with my example commit.
I thought I did. And not only for Fedora releases ;-)
https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/
Is there any way to make this portable across all Fedora releases and EPEL? I'd like to avoid %ifdeffery if possible.
Regards, Dominik
On Monday, July 20, 2020 9:23:46 PM CEST Dominik 'Rathann' Mierzejewski wrote:
On Monday, 20 July 2020 at 20:46, Kamil Dudka wrote:
On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
Or you could just use "%global __cmake_in_source_build 1" which reverts to the previous behavior.
That does not make any sense. The packages I talk about have used out of source builds since forever.
Or you could *actually* make it do it out of source even with older Fedora releases as I did with my example commit.
I thought I did. And not only for Fedora releases ;-)
https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/
Is there any way to make this portable across all Fedora releases and EPEL? I'd like to avoid %ifdeffery if possible.
The fix I mentioned (appending -B.) worked for me on EPEL-7, EPEL-8 and Fedora, without any %ifdef.
Kamil
Regards, Dominik
On Tue, Jul 21, 2020 at 3:32 AM Kamil Dudka kdudka@redhat.com wrote:
On Monday, July 20, 2020 9:23:46 PM CEST Dominik 'Rathann' Mierzejewski wrote:
On Monday, 20 July 2020 at 20:46, Kamil Dudka wrote:
On Monday, July 20, 2020 8:35:37 PM CEST Neal Gompa wrote:
Or you could just use "%global __cmake_in_source_build 1" which reverts to the previous behavior.
That does not make any sense. The packages I talk about have used out of source builds since forever.
Or you could *actually* make it do it out of source even with older Fedora releases as I did with my example commit.
I thought I did. And not only for Fedora releases ;-)
https://copr.fedorainfracloud.org/coprs/kdudka/predator/build/1565751/
Is there any way to make this portable across all Fedora releases and EPEL? I'd like to avoid %ifdeffery if possible.
The fix I mentioned (appending -B.) worked for me on EPEL-7, EPEL-8 and Fedora, without any %ifdef.
That's odd, it shouldn't work, since -B wasn't introduced until CMake 3.13...
On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
That's odd, it shouldn't work,
I believe it does.
since -B wasn't introduced until CMake 3.13...
You only need working -B option to override a previously specified -B option. Otherwise CMake defaults to the current working directory as build directory. So appending -B. is a no-op on EPEL-7 and EPEL-8, which were not affected by this change.
Kamil
On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka kdudka@redhat.com wrote:
On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
That's odd, it shouldn't work,
I believe it does.
since -B wasn't introduced until CMake 3.13...
You only need working -B option to override a previously specified -B option. Otherwise CMake defaults to the current working directory as build directory. So appending -B. is a no-op on EPEL-7 and EPEL-8, which were not affected by this change.
So my understanding is that the option shouldn't work at all on CMake 3.11 in EPEL 8, as it does not exist in the man page: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html
On Tuesday, July 21, 2020 3:41:02 PM CEST Neal Gompa wrote:
On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka kdudka@redhat.com wrote:
On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
That's odd, it shouldn't work,
I believe it does.
since -B wasn't introduced until CMake 3.13...
You only need working -B option to override a previously specified -B option. Otherwise CMake defaults to the current working directory as build directory. So appending -B. is a no-op on EPEL-7 and EPEL-8, which were not affected by this change.
So my understanding is that the option shouldn't work at all on CMake 3.11 in EPEL 8, as it does not exist in the man page: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html
What exactly do you mean by "work"? If the option does not take any effect, that is perfectly fine because the Fedora change did not reach EPEL-8 (yet).
Or are you saying that using cmake -B. breaks EPEL-8 builds? Do you have any example?
Kamil
On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka kdudka@redhat.com wrote:
On Tuesday, July 21, 2020 3:41:02 PM CEST Neal Gompa wrote:
On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka kdudka@redhat.com wrote:
On Tuesday, July 21, 2020 12:39:55 PM CEST Neal Gompa wrote:
That's odd, it shouldn't work,
I believe it does.
since -B wasn't introduced until CMake 3.13...
You only need working -B option to override a previously specified -B option. Otherwise CMake defaults to the current working directory as build directory. So appending -B. is a no-op on EPEL-7 and EPEL-8, which were not affected by this change.
So my understanding is that the option shouldn't work at all on CMake 3.11 in EPEL 8, as it does not exist in the man page: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html
What exactly do you mean by "work"? If the option does not take any effect, that is perfectly fine because the Fedora change did not reach EPEL-8 (yet).
Or are you saying that using cmake -B. breaks EPEL-8 builds? Do you have any example?
I'm saying that doing that is supposed to break CMake on RHEL 8 because the option isn't supported. That's *why* I haven't yet backported the macros to EPEL 8. I am trying to work around missing features in CMake.
On Tuesday, July 21, 2020 4:02:29 PM CEST Neal Gompa wrote:
On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka kdudka@redhat.com wrote:
What exactly do you mean by "work"? If the option does not take any effect, that is perfectly fine because the Fedora change did not reach EPEL-8 (yet).
Or are you saying that using cmake -B. breaks EPEL-8 builds? Do you have any example?
I'm saying that doing that is supposed to break CMake on RHEL 8 because the option isn't supported. That's *why* I haven't yet backported the macros to EPEL 8. I am trying to work around missing features in CMake.
That does not really matter. My fix based on `-B.` works fine on Fedora and does not break anything on EPEL-7 and EPEL-8. It is currently not needed on EPEL-8 but it is harmless and I am able to use a single spec file (without any %ifdef) everywhere. In case the backward-incompatible change of the %cmake macro reaches EPEL-8 (after an update of cmake), the fix will work there, too.
Kamil
Neal Gompa wrote:
So my understanding is that the option shouldn't work at all on CMake 3.11 in EPEL 8, as it does not exist in the man page: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html
Older CMake versions had undocumented -H and -B options, which were supposed to be always used together. In CMake 3.13, -H was renamed to -S, they were made independent of each other, and they became documented.
See: https://cgold.readthedocs.io/en/latest/glossary/-B.html
I guess CMake 3.11 silently ignores the lone "-B.".
Kevin Kofler
On Monday, 20 July 2020 at 19:37, Neal Gompa wrote:
On Mon, Jul 20, 2020 at 1:29 PM Kaleb Keithley kkeithle@redhat.com wrote:
On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11) with cmake-3.18.0-1.fc33 and the build(s) were successful.
Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake- 3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with:
...
- make -j5
make: *** No targets specified and no makefile found. Stop.
see, e.g., https://koji.fedoraproject.org/koji/watchlogs?taskID=47508501
No changes to the .spec other than Release and %changelog.
Anyone else seeing this?
This is because ceph is not adapted yet for https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
Your spec file is a complete mess, so I have not yet touched it to fix it.
Here's an example of how I fixed one package: https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576...
This doesn't help to fix this:
%build mkdir -p build cd build %cmake3 \ .. %make_build
Help?
Regards, Dominik
Le 20/07/2020 à 21:34, Dominik 'Rathann' Mierzejewski a écrit :
This doesn't help to fix this:
%build mkdir -p build cd build %cmake3 \ .. %make_build
Help?
Have you try "%cmake3 -S .. -B ."
This should override the default "-S ."
As the previous version require the sources directory it seems better to always give it, even with newer version, but using the -S option.
BTW, having to add condition around %cmake_* usage (for EL-8) is a nightmare, and having them added in some EPEL specific package is NOT a proper solution.
Remi
On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa ngompa13@gmail.com wrote:
Your spec file is a complete mess, so I have not yet touched it to fix it.
Not _my_ spec file. Is this another episode of whinging about %ifdef SUSE, then I suggest you direct your comments at https://github.com/ceph/ceph/blob/master/ceph.spec.in. I'm sure they will appreciate your usual candor.
Because I'm sure what everyone wants is to maintain two files that are 99% the same. Especially when there are conditionals.
Here's an example of how I fixed one package:
https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576...
That might actually be helpful.
More constructive comments. Less snark.
--
Kaleb
On Mon, Jul 20, 2020 at 3:44 PM Kaleb Keithley kkeithle@redhat.com wrote:
On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa ngompa13@gmail.com wrote:
Your spec file is a complete mess, so I have not yet touched it to fix it.
Not _my_ spec file. Is this another episode of whinging about %ifdef SUSE, then I suggest you direct your comments at https://github.com/ceph/ceph/blob/master/ceph.spec.in. I'm sure they will appreciate your usual candor.
Because I'm sure what everyone wants is to maintain two files that are 99% the same. Especially when there are conditionals.
Hardly. I maintain plenty of triple-distro (RH/Fedora, SUSE, and Debian/Ubuntu) spec files of more complex software that are cleaner than Ceph's.
The mess is because the Ceph spec file is tremendously regressive compared to current standards for RH/Fedora and SUSE packaging. It doesn't even have the minor fixes I made upstream to the spec for libexecdir stuff.
Here's an example of how I fixed one package: https://src.fedoraproject.org/rpms/allegro5/c/2a59aa1daea345823b81c9b396f576...
That might actually be helpful.
More constructive comments. Less snark.
I *was* going to fix it at some point, but having to parse a complex spec file takes time and effort. And I *really* doubt anyone has seriously analyzed that spec file in recent years.
Even *I* haven't completed my *own* analysis of it for rewriting it for my personal use, since there's far too much cruft in the current spec for me to be comfortable with me using for personal builds.
-- 真実はいつも一つ！/ Always, there's only one truth!
You can work around it for now with %global __cmake_in_source_build 1
-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, July 20, 2020 12:27 PM, Kaleb Keithley kkeithle@redhat.com wrote:
On 2020-07-17 I built ceph-15.2.4-5 (and ceph-15.2.4-6 --target=f33-java11) with cmake-3.18.0-1.fc33 and the build(s) were successful.
Today, with cmake-3.18.0-2.fc33 (which I guess is a respin of cmake- 3.18.0-1.fc33.1, a.k.a. 3.18.0-1.1) my scratch builds are failing with:
...
- make -j5
make: *** No targets specified and no makefile found. Stop.
see, e.g., https://koji.fedoraproject.org/koji/watchlogs?taskID=47508501
No changes to the .spec other than Release and %changelog.
Anyone else seeing this?
--
Kaleb
-
Dominik 'Rathann' Mierzejewski -
Gwyn Ciesla -
Kaleb Keithley -
Kamil Dudka -
Kevin Kofler -
Neal Gompa -
Remi Collet