http://bugzilla.suse.com/show_bug.cgi?id=1091864 Andreas Schneider changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[RPM] The %make_install |[RPM] The %make_jobs macro |macro from marcos.cmake |from marcos.cmake gets |gets overwritten by |overwritten by macro.qt5 |macro.qt5 | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c1 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |fvogt@suse.com --- Comment #1 from Fabian Vogt --- Same for macros.kde4 apparently. Removing it might break stuff - needs to be tested. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c3 --- Comment #3 from Fabian Vogt --- (In reply to Marcus Rückert from comment #2)

maybe use the definition from cmake everywhere?

To me it looks like with the use of %__builder, the %make_jobs macro is now cmake-specific. It should IMO be renamed. %make_jobs should just invoke plain make with arguments, where that is defined then should not matter. Once that is done, the definition from macros.kde4 and macros.qt5 can be removed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c5 --- Comment #5 from Fabian Vogt --- (In reply to Marcus Rückert from comment #4)

yeah but the %__builder defaults to "make" no?

so we could avoid having to use yet another macro for it.

Yes, but there is a slim chance that that could break some builds. Qt 5.11 is checked in, so I'll do a submission and see what breaks. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c7 --- Comment #7 from Marcus Rückert ---

While you're at it - can you move the file from /etc/rpm/macros.cmake to /usr/lib/rpm/macros.d/cmake?

Does that work on code 11/code 12 already or is that code 15 and newer? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c9 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P1 - Urgent Component|Development |Development Version|Current |Leap 15.0 Product|openSUSE Tumbleweed |openSUSE Distribution Target Milestone|--- |Leap 15.0 Severity|Normal |Critical --- Comment #9 from Fabian Vogt --- macros.cmake in Leap 15.0 now breaks building Qt as it overrides %make_jobs with an incompatible macro. Please fix ASAP. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c11 --- Comment #11 from Fabian Vogt --- (In reply to Marcus Rückert from comment #10)

I would still push for a shared make_jobs macro that works for both.

I fully agree - but currently the cmake-provided macro breaks Qt builds while the Qt-provided macro doesn't break cmake builds (ninja isn't used yet). The %make_jobs macro implies that "make" is used any not "ninja", so IMO that macro needs to be renamed into %build_jobs or something else. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c13 --- Comment #13 from Simon Lees --- (In reply to Fabian Vogt from comment #11)

(In reply to Marcus Rückert from comment #10)

...

I would still push for a shared make_jobs macro that works for both.

I fully agree - but currently the cmake-provided macro breaks Qt builds while the Qt-provided macro doesn't break cmake builds (ninja isn't used yet).

The %make_jobs macro implies that "make" is used any not "ninja", so IMO that macro needs to be renamed into %build_jobs or something else.

The macro has been renamed to %cmake_build in tumbleweed to be more consistent -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c15 --- Comment #15 from Marcus Rückert --- (In reply to Simon Lees from comment #13)

(In reply to Fabian Vogt from comment #11)

...

(In reply to Marcus Rückert from comment #10)

...

I would still push for a shared make_jobs macro that works for both.

I fully agree - but currently the cmake-provided macro breaks Qt builds while the Qt-provided macro doesn't break cmake builds (ninja isn't used yet).

The %make_jobs macro implies that "make" is used any not "ninja", so IMO that macro needs to be renamed into %build_jobs or something else.

The macro has been renamed to %cmake_build in tumbleweed to be more consistent

did you check how many packages that will break? why not just use the version of the macro provided above which makes it work in all cases? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c17 --- Comment #17 from Simon Lees --- (In reply to Simon Lees from comment #16)

(In reply to Marcus Rückert from comment #15)

...

(In reply to Simon Lees from comment #13)

...

(In reply to Fabian Vogt from comment #11)

...

(In reply to Marcus Rückert from comment #10)

...

I would still push for a shared make_jobs macro that works for both.

I fully agree - but currently the cmake-provided macro breaks Qt builds while the Qt-provided macro doesn't break cmake builds (ninja isn't used yet).

The %make_jobs macro implies that "make" is used any not "ninja", so IMO that macro needs to be renamed into %build_jobs or something else.

The macro has been renamed to %cmake_build in tumbleweed to be more consistent

did you check how many packages that will break?

why not just use the version of the macro provided above which makes it work in all cases?

Personally I didn't make the change Tomas did, for now the macro has a fallback mode and over the next couple of weeks he plans to go through and submit updates to all the affected packages then remove the fallback once they are all accepted into factory. His motivation wasn't fixing this issue but making the cmake macro's function in the same way as the macros for other build systems.

I have no problem with also making the macro behave in the way you had above, it just hadn't reached the top of my todo list yet. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c19 Simon Lees changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(simonf.lees@suse. | |com) | --- Comment #19 from Simon Lees --- (In reply to Marcus Rückert from comment #12)

so the thing that is broken with the cmake version of the %make_jobs macro (compared to the version in the Qt package)

is

%make_jobs -C build/something

the params end up after the the %endif of the cmake make_jobs macro

the main difference between the 2 macros is enabling verbose mode and support for ninja. the first step is already handled by the __builder macro. but the verbose flag is why we need the %if, so my proposal would be the following change.

``` # added the %_make_output_sync from %make_build here as it is useful. %__builder_verbose \ %if "%__builder" == "%__make" \ %{?_make_output_sync} VERBOSE=1 \\\ %else \ -v \\\ %endif \ %{nil}

%make_jobs %__builder \\%__builder_verbose %{?_smp_mflags} ```

this makes Fabian's usecase work. now the question is on how do we make this change in a backwards compatible way. in ideal world we would just move the whole %make_jobs macro to the rpm macros file but that would require a maintenance update for rpm and everyone building against :Update.

or we just copy the macro around and have a comment that asks people to keep the macro in sync between the different places. thoughts?

I am now preparing a cmake update for SLE 15 sp1 so i'll include this change unless you see a good reason not to. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1091864 http://bugzilla.suse.com/show_bug.cgi?id=1091864#c23 Vladimir Siman changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vladimir.siman@suse.com --- Comment #23 from Vladimir Siman --- Created attachment 845839 --> http://bugzilla.suse.com/attachment.cgi?id=845839&action=edit test attachment -- You are receiving this mail because: You are on the CC list for the bug.