Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-23 Thread Remi Collet
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-22 Thread Kevin Kofler
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Kamil Dudka
On Tuesday, July 21, 2020 4:02:29 PM CEST Neal Gompa wrote:
> On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Neal Gompa
On Tue, Jul 21, 2020 at 9:51 AM Kamil Dudka  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  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.

-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Kamil Dudka
On Tuesday, July 21, 2020 3:41:02 PM CEST Neal Gompa wrote:
> On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka  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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Neal Gompa
On Tue, Jul 21, 2020 at 9:04 AM Kamil Dudka  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

-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Kamil Dudka
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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Neal Gompa
On Tue, Jul 21, 2020 at 3:32 AM Kamil Dudka  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...



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-21 Thread Kamil Dudka
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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Neal Gompa
On Mon, Jul 20, 2020 at 3:44 PM Kaleb Keithley  wrote:
>
> On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa  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/2a59aa1daea345823b81c9b396f5766cba54da78
>
>
> 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Kaleb Keithley
On Mon, Jul 20, 2020 at 1:48 PM Neal Gompa  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/2a59aa1daea345823b81c9b396f5766cba54da78


That might actually be helpful.

More constructive comments. Less snark.

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Dominik 'Rathann' Mierzejewski
On Monday, 20 July 2020 at 19:37, Neal Gompa wrote:
> On Mon, Jul 20, 2020 at 1:29 PM Kaleb Keithley  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/2a59aa1daea345823b81c9b396f5766cba54da78

This doesn't help to fix this:

%build
mkdir -p build
cd build
%cmake3 \
..
%make_build

Help?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Dominik 'Rathann' Mierzejewski
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
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Kamil Dudka
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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Neal Gompa
On Mon, Jul 20, 2020 at 2:31 PM Kamil Dudka  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:
>
> https://github.com/kdudka/predator/commit/34ef2198
>

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.


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Kamil Dudka
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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Gwyn Ciesla via devel
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  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

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Neal Gompa
On Mon, Jul 20, 2020 at 1:29 PM Kaleb Keithley  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/2a59aa1daea345823b81c9b396f5766cba54da78



-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


cmake-3.18.0-2.fc33 (or 3.18.0-1.fc33.1) in rawhide is broken!

2020-07-20 Thread Kaleb Keithley
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org