Description of problem: Makefiles generated by mingw[32/64]-cmake are verbose by default, and do not follow the VERBOSE variable. Version-Release number of selected component (if applicable): mingw32-filesystem-99-1.fc19.noarch mingw64-filesystem-99-1.fc19.noarch How reproducible: 140% of the time (in Russia), 100% of the time (otherwise) Steps to Reproduce: 1. Pick your favorite portable cmake-based project and clone its source 2. mkdir build-w32 && cd build-w32 3. cmake .. 4. make Actual results: Overly verbose console output that shows compiler calls and a lot of things one does not usually care about. Expected results: Nice clean console output. Additional info: VERBOSE=1 cmake should bring up the verbose output. VERBOSE=0 cmake is _still_ verbose.
I assume you're talking about the mingw32-cmake and mingw64-cmake wrapper scripts instead of calling cmake directly? The behaviour we have right now is exactly the same as the RPM macros used by the native cmake package. These are defined in /usr/lib/rpm/macros.d/macros.cmake which contains -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON. This can also be observed by running this command: rpm --eval '%cmake' The mingw32-cmake and mingw64-cmake wrappers internally call the %mingw32_cmake and %mingw64_cmake RPM macros which are defined in /etc/rpm/macros.mingw32 and /etc/rpm/macros.mingw64. While building RPM package using the Fedora MinGW RPM macros we DO want to have verbose build logs as it helps with investigating any potential build failures. I don't plan on changing this. If you aren't interested in verbose builds, then you can manually run cmake with the correct arguments for cross-compiling binaries. The complete cmake command which the mingw32-cmake and mingw64-cmake wrapper scripts run can be found out by running rpm --eval '%mingw32_cmake' or rpm --eval '%mingw64_cmake'. By manually running cmake you can decide for yourself which arguments you're interested in. If you can come up with a patch which makes the mingw32-cmake/mingw64-cmake wrappers non-verbose by default while retaining the verbose option during RPM builds (without duplicating code) I'm willing to review and apply such a change to the mingw-filesystem package
(In reply to Erik van Pienbroek from comment #1) > I assume you're talking about the mingw32-cmake and mingw64-cmake wrapper > scripts instead of calling cmake directly? > Yes. I forgot to type the "mingw32-" in my original report. Sorry about that. > While building RPM package using the Fedora MinGW RPM macros we DO want to > have verbose build logs as it helps with investigating any potential build > failures. I don't plan on changing this. > Well, this can be achieved in either one of the two very simple ways within the spec file: VERBOSE=1 make %{?_smp_mflags} %cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON Let the maintainer decide whether or not he wants verbose logs in his package. I have verbose logs enabled in a couple of my packages (non-mingw) that have at times been problematic, but not in others. Forcing everyone else to deal with verbose makefiles is the wrong approach IMHO. > If you aren't interested in verbose builds, then you can manually run cmake > with the correct arguments for cross-compiling binaries. The complete cmake > command which the mingw32-cmake and mingw64-cmake wrapper scripts run can be > found out by running rpm --eval '%mingw32_cmake' or rpm --eval > '%mingw64_cmake'. By manually running cmake you can decide for yourself > which arguments you're interested in. > I would say optimize for the common case. Invoking mingw[32/64]-cmake is far more common than editing a .spec file once to control verbosity. This is a perfect example of seemingly correct components not inter-operating perfectly. My opinion is that the RPM macros should not decide for you what verbosity level you want to have. Considering that the decision to not have verbose makefiles is not final, it should be the default. OTOH, once we go for verbose makefiles in the mingw32-cmake step, the decision can no longer be changed.
I think it would be better to start a discussion about this subject on the fedora-devel mailing list to find out the opinion of other users as well. We (the Fedora MinGW SIG) are following the defaults as used by the native CMake package, so if you want to get things changed it's better to start there.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
mingw-filesystem-100-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc22
mingw-filesystem-100-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc21
mingw-filesystem-100-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc20
mingw-filesystem-100-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
mingw-filesystem-100-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
mingw-filesystem-100-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.