On Tue, Aug 4, 2020 at 12:20 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Mon, Aug 3, 2020 at 4:21 PM Alexander Ploumistos > <alex.ploumistos@xxxxxxxxx> wrote: > > > > Hi Neal, > > > > On Mon, Aug 3, 2020 at 8:37 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > So if a spec file is supposed to work on F31 to F33, "%undefine > > __cmake_in_source_build" is all that's required? > > The %undefine will make Fedora 31 and Fedora 32 CMake behave the same > way as Fedora 33 CMake. > > After that, you can switch %make_build and %make_install macros to > %cmake_build and %cmake_install. > > Alternatively, if you %define __cmake_in_source_build 1, this will > make Fedora 33 CMake behave the same way as Fedora 31 and Fedora 32 > CMake, and then the old command flow works as before. > > I recommend using the %undefine behavior and switching to the new > macros, but you can make your own judgement. Thanks, going for %define felt like trying to postpone adjusting to the new guidelines. What about any "make target1 target2" between the %cmake* macros? Do they remain as they are? For the past couple of hours I've been testing every possible combination of the macros while trying to fix liborigin (which has a completely flat tree, save for its documentation) and no matter what I choose, I always end up with a directory or file being inaccessible to cmake. It is driving me crazy. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
