> On Aug. 26, 2015, 7:24 a.m., David Faure wrote: > > It sounds to me like ecm_mark_non_gui_executable doesn't do the right thing > > then, and should be fixed, instead? > > > > These are non gui executables, so from an "API" point of view, using this > > function is correct. > > > > Would we ever want a console window when running an app on windows? I guess > > not? > > So maybe we should do whatever "WIN32" does from within that function, if > > it's doable outside the add_executable call? > > Kevin Funk wrote: > It's rather that `ecm_mark_non_gui_executable` is has a misleading > meaning: "Marks an executable target as not being a GUI application" > > Well, in that case setting WIN32_EXECUTABLE to FALSE is *correct*, *but* > in fact marking an executable as console application on Windows implies the > executable showing a console window. I'm not sure if we should just switch > the description/behavior of `ecm_mark_non_gui_executable`, or just not use it > (as I did). Honestly I think we'd be better off just not using it (it doesn't > really increase convenience, in fact my patch just removes code and still > "fixes" things). > > > Documentation of WIN32_EXECUTABLE: > > WIN32_EXECUTABLE > Build an executable with a WinMain entry point on windows. > > When this property is set to true the executable when linked on Windows > will be created with a WinMain() entry point instead of just main(). This > makes it a GUI executable instead of a console application. See the > CMAKE_MFC_FLAG variable documentation to configure use of MFC for WinMain > executables. This property is initialized by the value of the variable > CMAKE_WIN32_EXECUTABLE if it is set when a target is created. > > > http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html#prop_tgt:WIN32_EXECUTABLE > > David Faure wrote: > I think what you're missing is that ecm_mark_non_gui_executable aims at > "doing the right thing on all platforms", which includes having no .app > bundle on OSX. Your patch goes back to unwanted app bundles on OSX, I presume. > This is why we should fix ecm_mark_non_gui_executable rather than not use > it. Also for a linux developer it's easier to think in terms of "mark as non > gui" than "do I need that weird WIN32 thing in there?". > > But I'm starting to understand something. Applications that are meant to > be used on the command line like kioclient, should be console apps on windows > i.e. use main() instead of WinMain(), otherwise we can't see any output, is > that right? > > So we don't have two cases (gui and non gui), we have three? > * GUI application (user visible) > * helper binary (libexec style). Not user visible. Should be WIN32 to > avoid a console window. > * command line tool (console app, "user visible" in the console). Should > not be WIN32. > > In that case we should have a different ecm macro for the second item in > that list, that's what we're missing, isn't it? > > On OSX, AFAIU, the last two would be "without app bundle". > > Kevin Funk wrote: > I know about OSX bundles. MACOSX_BUNDLE is FALSE by default. However, I > just noticed we have this defined somewhere in ECM (thus MACOSX_BUNDLE is > indeed TRUE by default b/c of CMAKE_MACOSX_BUNDLE being ON...) > > ``` > # By default, create 'GUI' executables. This can be reverted on a > per-target basis > # using ECMMarkNonGuiExecutable > # Since CMake 2.8.8 > set(CMAKE_WIN32_EXECUTABLE ON) > set(CMAKE_MACOSX_BUNDLE ON) > ``` > > Didn't realize until now... > > I totally agree with your remark; there are three cases. Let's solve them > by: > * (1) -> do nothing > * (2) -> ecm_mark_helper_executable() (to be done, sets WIN32 to TRUE, > MACOSX_BUNDLE to FALSE) > * (3) -> ecm_mark_nongui_executable() > > Makes sense?
Yes, very much. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124905/#review84389 ----------------------------------------------------------- On Aug. 27, 2015, 7:31 a.m., Kevin Funk wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124905/ > ----------------------------------------------------------- > > (Updated Aug. 27, 2015, 7:31 a.m.) > > > Review request for KDE Frameworks, Alex Merry, David Faure, and Boudewijn > Rempt. > > > Repository: kio > > > Description > ------- > > Win: Hide console window for binaries in LIBEXEC > > > Diffs > ----- > > src/ioslaves/http/CMakeLists.txt 76a8e2800b84c312431cc1996ac81d1ef6fb5cfc > src/ioslaves/http/kcookiejar/CMakeLists.txt > 7b4778d1f67c1ad9f9edcaa4692b39ee6fe3f365 > src/kioexec/CMakeLists.txt 91284a3a61b86770b4d1939da52d256840803608 > src/kioslave/CMakeLists.txt e02febd380b268c596e8ecc3b745b6f50993ab4e > src/kpac/CMakeLists.txt fc5989714480ca49b5bd72e1c7b458b26bd0d9bc > > Diff: https://git.reviewboard.kde.org/r/124905/diff/ > > > Testing > ------- > > > Thanks, > > Kevin Funk > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel