Bug 359572

Summary: Windows build, debug library is not d suffixed.
Product: [Frameworks and Libraries] extra-cmake-modules Reporter: Mark <markg85>
Component: generalAssignee: Alex Merry <alex.merry>
Status: CONFIRMED ---    
Severity: normal CC: ecm-bugs-null, faure, kdelibs-bugs-null, winter
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Other   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Mark 2016-02-19 12:15:15 UTC 
Hi,

When compiling KArchive on windows (cmake for the configure step ... -DCMAKE_BUILD_TYPE=debug ..., nmake for building) then you end up with KF5Archive.dll, not KF5Archived.dll (note the "d").

Also, the file "qt_KArchive.pri" misses a "QT.KArchive.bins" line, it's where the DLL is stored.

Lastly, when running a QMake project with QT += KArchive then at runtime it will search for KF5Archive.dll instead of KF5Archived.dll.

Having the debug library to be "d" suffixed would be best since that allows one to run the app in debug and release mode. Also, Qt does this as well for all libraries so i guess KF5 (specifically tier 1 libraries) should follow that example.

P.s. the version field here only goes as far as 5.1.0... I have 5.19.0 ;)

Best regards,
Mark

Reproducible: Always
Comment 1 David Faure 2016-02-21 13:50:52 UTC 
More of an ECM issue than specifically karchive -> reassigning.

I'll fix the pri file, that's my code. For the rest, I'm not sure where the filename comes from exactly.

Your line "Lastly" surprises me --- if it points to the actual name of the DLL, then it should work, with the current naming, no?

PS: I know about the version field, I've been asking for a way to script this, I'm not going to create 70 versions in bugzilla by hand every month...
Comment 2 Mark 2016-02-21 14:15:06 UTC 
 > Your line "Lastly" surprises me --- if it points to the actual name of the
> DLL, then it should work, with the current naming, no?

That works as long as the dll name is KF5Archive.dll (for debug and release, no d suffix for the debug library) AND when using QT += KArchive.

When renaming the debug DLL to have the d suffix that doesn't work anymore. At least not with QT += KArchive (it doesn't know KF5Archived.dll?). That only works if you manually add the include path and manually add the appropriate library for debug and release (LIBS += -l...), which kinda makes using "QT += KArchive" useless since it's being done manually in this case. I can easily work around this in the project where KArchive is used, but I was kinda expecting the dll's to work the same as Qt's own dll's (which do have a d suffix for debug) and have the QT += foo magically use the appropriate DLL based on the build setting.
Comment 3 Stephen Kelly 2016-03-13 17:33:34 UTC 
I guess we currently just let cmake do whatever it does by default here. What does cmake do regarding windows here?
Comment 4 Allen Winter 2016-03-13 18:10:03 UTC 
recently I added code like this to a project.
Might be of use to you.

  string(TOUPPER ${CMAKE_BUILD_TYPE} UPPER_BUILD_TYPE)
  if(${UPPER_BUILD_TYPE} MATCHES "^DEBUG")
    set_target_properties(your_library PROPERTIES DEBUG_POSTFIX "d")
  endif()
Comment 5 Mark 2016-03-13 19:11:34 UTC 
(In reply to Allen Winter from comment #4)
> recently I added code like this to a project.
> Might be of use to you.
> 
>   string(TOUPPER ${CMAKE_BUILD_TYPE} UPPER_BUILD_TYPE)
>   if(${UPPER_BUILD_TYPE} MATCHES "^DEBUG")
>     set_target_properties(your_library PROPERTIES DEBUG_POSTFIX "d")
>   endif()

I don't think it's that easy.

That would probably work and create a d-suffixed library, however using "QT += KArchive" would probably still try to load the non d-suffixed library. Unless set_target_properties also handles the qmake stuff?

Also, adding this manually is a workaround. This should be addressed in ECM so that all build (on windows) get d-suffixed debug builds.