[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2017-11-05 Thread Christophe Giboudeaux
https://bugs.kde.org/show_bug.cgi?id=359572

Christophe Giboudeaux  changed:

   What|Removed |Added

   Assignee|steve...@gmail.com  |alex.me...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-03-13 Thread Mark via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

--- Comment #5 from Mark  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.


[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-03-13 Thread Allen Winter via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

Allen Winter  changed:

   What|Removed |Added

 CC||win...@kde.org

--- Comment #4 from Allen Winter  ---
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()

-- 
You are receiving this mail because:
You are watching all bug changes.


[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-03-13 Thread Stephen Kelly via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

--- Comment #3 from Stephen Kelly  ---
I guess we currently just let cmake do whatever it does by default here. What
does cmake do regarding windows here?

-- 
You are receiving this mail because:
You are watching all bug changes.


[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-02-27 Thread David Faure via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

David Faure  changed:

   What|Removed |Added

   Assignee|alex.me...@kde.org  |steve...@gmail.com
 CC||fa...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.


[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-02-21 Thread Mark via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

--- Comment #2 from Mark  ---
 > 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.

-- 
You are receiving this mail because:
You are watching all bug changes.


[extra-cmake-modules] [Bug 359572] Windows build, debug library is not d suffixed.

2016-02-21 Thread David Faure via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359572

David Faure  changed:

   What|Removed |Added

 CC||ecm-bugs-n...@kde.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED
  Component|general |general
Product|frameworks-karchive |extra-cmake-modules
   Assignee|fa...@kde.org   |alex.me...@kde.org

--- Comment #1 from David Faure  ---
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...

-- 
You are receiving this mail because:
You are watching all bug changes.