> 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".

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?


- Kevin


-----------------------------------------------------------
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

Reply via email to