Re: Is ECM a good place for implementing Nim support in CMake?

[Albert Astals Cid]

El divendres, 19 d’abril del 2024, a les 11:17:09 (CEST), Anna (cybertailor) 
Vyalkova va escriure:
> Hi,
> 
> I'd like to develop Nim applications (with possible GUI support via
> nimqt) but this language lacks support for any standard build system.
> 
> So that's the thing I'm focused on right now (just happened to also be
> my favorite thing).
> 
> Alternatives I considered:
> 
> 1. Procedure described in "CMakeAddNewLanguage.txt". First of all,
> that's scary and second it doesn't cover my use case: Nim is not a
> compiler but rather a transpiler. It compiles Nim code into C/C++/JS
> code and then calls system compiler to get native binaries. These steps
> could be separated.
> 
> 2. Going with my own "nim-for-cmake" module library. That's possible but
> requires lots of boilerplate code that can be avoided if these modules
> become part of ECM.
> 
> I've implemented an alternative build system for Nim's "nimble" packages
> before so I know the necessary steps: 1) find the compiler, 2) find the
> deps, 3) generate a json-script, 4) extract the depfiles, 5) execute the
> script.
> 
> Can I start making such ECM module or should it be a separate CMake
> module library?

You will probably find more people that know about ECM in kde frameworks devel 
mailing list than here, this list is nowadays pretty dormant.

My suggetsion would be, talk to the cmake folks, they are a relatively open 
bunch of people that like their build system to support as many things 
possible and what you really want is to have support in cmake itself, not 
having to include some extra stuff to make it work.

Cheers,
  Albert

D24841: Use modern way to set the C/CXX standad

[Albert Astals Cid]

aacid added a comment.


  If you want to increase cmake dependency, we should at least increase it to 
3.5
  
  https://repology.org/project/cmake/badges

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D24841

To: vonreth, dfaure, cullmann
Cc: aacid, chehrlic, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, 
bencreasy, michaelh, ngraham, bruns

D24568: Provide clang-format target with a common KDE style file

[Albert Astals Cid]

aacid added a comment.


  If the KDE Frameworks developers have agreed to a common style, then yes, 
naming it KDE Frameworks style makes sense :)

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D24568

To: cullmann, #frameworks
Cc: aacid, davidedmundson, dhaumann, apol, ognarb, kde-frameworks-devel, 
kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

D24568: Provide clang-format target with a common KDE style file

[Albert Astals Cid]

aacid added a comment.


  > common KDE style file
  
  There's no such thing as a common KDE style

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D24568

To: cullmann, #frameworks
Cc: aacid, davidedmundson, dhaumann, apol, ognarb, kde-frameworks-devel, 
kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns

D19005: android: don't default to gcc anymore

[Albert Astals Cid]

aacid closed this revision.
aacid added a comment.


  Talked with Aleix, we're deciding to drop this for the moment

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D19005

To: apol, #frameworks, vkrause
Cc: aacid, kde-frameworks-devel, kde-buildsystem, LeGast00n, sbergeron, 
bencreasy, michaelh, ngraham, bruns

D20349: Unconditionally enable -DQT_STRICT_ITERATORS, not just in debug mode

[Albert Astals Cid]

aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D20349

To: dfaure, dvratil, mlaurent, aacid
Cc: aacid, kde-buildsystem, kde-frameworks-devel, bencreasy, michaelh, ngraham, 
bruns

D20349: Unconditionally enable -DQT_STRICT_ITERATORS, not just in debug mode

[Albert Astals Cid]

aacid added a comment.


  Are we sure we don't break code by introducing this? Or we're just going to 
play Whac-A-Mole with compile errors until all it's compiling again?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D20349

To: dfaure, dvratil, mlaurent
Cc: aacid, kde-buildsystem, kde-frameworks-devel, bencreasy, michaelh, ngraham, 
bruns

D18947: Bring FindUDev.cmake up to ECM standards

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> FindUDev.cmake:75
> +IMPORTED_LOCATION "${UDev_LIBRARIES}"
> +INTERFACE_INCLUDE_DIRECTORIES "${UDev_INCLUDE_DIRS}"
> +)

Do we need a 
INTERFACE_COMPILER_DEFINITIONS "${UDev_DEFINITIONS}"
just in case that udev adds some definitions at some point?

REPOSITORY
  R245 Solid

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D18947

To: vkrause, #build_system, cgiboudeaux, apol
Cc: aacid, apol, kde-frameworks-devel, michaelh, ngraham, bruns

D18952: new find module for Canberra

[Albert Astals Cid]

aacid added a comment.


  Yes, imported targets are the future/present :)
  
  Canberra::Canberra sounds good to me as target name

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18952

To: sitter, cgiboudeaux
Cc: aacid, apol, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[Albert Astals Cid]

aacid added a comment.


  Oh, Hannah updated the summary, so an unknown option makes visibility stuff 
fail?
  
  Wow Apple really did a bad fork of clang if that's what's happening.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18547

To: vonreth, aacid, apol, dfaure, rjvbb, bcooksley
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[Albert Astals Cid]

aacid added a comment.


  You sure about that? AFAICS from 
https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/346/console 
it's just a warning, otherwise, ninja would stop after the first error, and it 
continues until a linking failure happens

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18547

To: vonreth, aacid, apol, dfaure, rjvbb, bcooksley
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[Albert Astals Cid]

aacid added a comment.


  Why?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18547

To: vonreth
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

aacid added a comment.


  In D18167#398076 , @graesslin 
wrote:
  
  > The human error exists as long as clang-tidy is not used. What I fear is 
that someone does a hand porting - we have seen several attempts to do that in 
KWin from various developers. If devs don't know and now fix the warnings, they 
can bring in human error.
  
  
  The nice thing about override is that the space for human error is *very* 
thin, it either compiles and then it's good or it doesn't compile and then it's 
bad.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18167

To: aacid
Cc: zzag, davidedmundson, kossebau, graesslin, apol, vkrause, 
kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

aacid added a comment.


  In D18167#398343 , @kossebau wrote:
  
  > only 3(?) days between proposal and commit was also a very rushy
  
  
  Check your dates better please, it's 9 days
  
  > Though then in this very case, my own take is to be pragmatic and see that 
this change makes sense in the end and that any active KDE software projects 
which have code left which should not be upgraded to C++11 and more recent 
standards should simply on their side opt-out from this warning.
  > 
  > While talking about it, not sure what is the better approach, I have seen 
different cmake-based approaches:
  > 
  >   string(REPLACE "-Wsuggest-override" "" CMAKE_CXX_FLAGS 
"${CMAKE_CXX_FLAGS}")
  > 
  > 
  >   check_cxx_compiler_flag("-Wno-suggest-override" HAS_WNO_SUGGEST_OVERRIDE)
  >   
  >   if (${HAS_WNO_SUGGEST_OVERRIDE})
  >   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-suggest-override" )
  >   endif()
  > 
  > 
  > What would cmake professionals use here?
  
  The second one seems better to me.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18167

To: aacid
Cc: zzag, davidedmundson, kossebau, graesslin, apol, vkrause, 
kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

aacid added a comment.


  In D18167#397020 , @graesslin 
wrote:
  
  > This causes in KWin 500+ new warnings. Do you really think it's a good idea 
to spam all of KDE with new compiler warnings. KDE has an old code base. We 
cannot enable warnings for the way you developed C++ for 20 years.
  
  
  These warnings are a good, thing, it's too easy to break an interface and 
never realize if you did not mark your functions as override.
  
  Anyway, if you don't want the warnings just disable them for gcc, you already 
made the decision to disable it for clang, so just extend it to gcc.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18167

To: aacid
Cc: graesslin, apol, vkrause, kde-frameworks-devel, kde-buildsystem, michaelh, 
ngraham, bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:7d73c6744f64: Move -Wsuggest-override -Wlogical-op to 
regular compiler settings (authored by aacid).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18167?vs=49189=49867

REVISION DETAIL
  https://phabricator.kde.org/D18167

AFFECTED FILES
  kde-modules/KDECompilerSettings.cmake
  kde-modules/KDEFrameworkCompilerSettings.cmake

To: aacid
Cc: apol, vkrause, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, 
bruns

D18345: Fix python binding generation for classes with deleted copy constructors

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:a2a404f9f924: Fix python binding generation for classes 
with deleted copy constructors (authored by aacid).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18345?vs=49775=49830

REVISION DETAIL
  https://phabricator.kde.org/D18345

AFFECTED FILES
  find-modules/sip_generator.py

To: aacid, lbeltrame
Cc: cgiboudeaux, skelly, kde-frameworks-devel, kde-buildsystem, michaelh, 
ngraham, bruns

D18345: Fix python binding generation for classes with deleted copy constructors

[Albert Astals Cid]

aacid added subscribers: skelly, cgiboudeaux.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18345

To: aacid
Cc: cgiboudeaux, skelly, kde-frameworks-devel, kde-buildsystem, michaelh, 
ngraham, bruns

D18345: Fix python binding generation for classes with deleted copy constructors

[Albert Astals Cid]

aacid created this revision.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
aacid requested review of this revision.

TEST PLAN
  kcoreaddons compiles again

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D18345

AFFECTED FILES
  find-modules/sip_generator.py

To: aacid
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

aacid added a comment.


  Since i have two +1 i'll commit this next saturday unless someone shouts in 
disagreement

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D18167

To: aacid
Cc: apol, vkrause, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, 
bruns

D18167: Move -Wsuggest-override -Wlogical-op to regular compiler settings

[Albert Astals Cid]

aacid created this revision.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
aacid requested review of this revision.

REVISION SUMMARY
  They really help making the code better so it's good to have all applications 
getting those warnings

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D18167

AFFECTED FILES
  kde-modules/KDECompilerSettings.cmake
  kde-modules/KDEFrameworkCompilerSettings.cmake

To: aacid
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14529: Android: Make sure Qm translations get loaded

[Albert Astals Cid]

aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  ok then i guess :)

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D14529

To: apol, #frameworks, aacid
Cc: svuorela, aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, 
bruns

D14966: Added support for disabling the loading of translations

[Albert Astals Cid]

aacid added a comment.


  I personally don't think this is the way to go and as said many times think 
that loading a custom translation for tests like ki18n way does is the way to 
go.
  
  Your issue with that seems to be that it won't work on windows, well then i'd 
say skip the test on windows until Qt gets better at it.
  
  But if someone else approves i'm not going to block on it.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D14966

To: habacker, aacid, dfaure
Cc: kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14778: Disable loading of translations when using 'C' locale

[Albert Astals Cid]

aacid added a comment.


  Honestly i think that test in kformattest is wrong and that it should contain 
it's own small minitranslation so that stuff works fine and then it should be
  
QCOMPARE(format.formatDecimalDuration(10), QStringLiteral("10 
milliseconds"));
  
  instead of
  
QCOMPARE(format.formatDecimalDuration(10), QStringLiteral("10 
millisecond(s)"));

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D14778

To: habacker, #frameworks, apol
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14778: Disable loading of translations when using 'C' locale

[Albert Astals Cid]

aacid added a comment.


  Doesn't setting the locale to en solve the same problem without needing to 
change ECM?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D14778

To: habacker, #frameworks, apol
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14529: Android: Make sure Qm translations get loaded

[Albert Astals Cid]

aacid added a comment.


  Ok, second option, we are actually installing these files ourselves, right?
  
  Can we install them somewhere "nicer"? like maybe 
QStandardPaths::StandardLocation(DataLocation) + optionally "/share" ?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D14529

To: apol, #frameworks
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D14529: Android: Make sure Qm translations get loaded

[Albert Astals Cid]

aacid added a comment.


  Is there a way we can get /../qt-reserved-files/share/ in a more natural way? 
fishing up to .. feels always like it'll break

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D14529

To: apol, #frameworks
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D10166: Add -Wlogical-op -Wzero-as-null-pointer-constant to KF5 warnings

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> apol wrote in KDEFrameworkCompilerSettings.cmake:70
> Maybe you can add `-Wzero-as-null-pointer-constant` to the if above which is 
> `gcc or clang`?

problem it's i also need the version check and since we already have it here it 
doesn't make the code any more simpler.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  arcpatch-D10166 (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D10166

To: aacid, cgiboudeaux
Cc: apol, kde-frameworks-devel, kde-buildsystem, cgiboudeaux, dhaumann, 
michaelh, ngraham, bruns

D10166: Add -Wlogical-op -Wzero-as-null-pointer-constant to KF5 warnings

[Albert Astals Cid]

aacid updated this revision to Diff 36684.
aacid added a comment.
Restricted Application edited subscribers, added: kde-buildsystem, 
kde-frameworks-devel; removed: Frameworks, Build System.


  make logical-op gcc only

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10166?vs=26151=36684

BRANCH
  arcpatch-D10166 (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D10166

AFFECTED FILES
  kde-modules/KDEFrameworkCompilerSettings.cmake

To: aacid
Cc: kde-frameworks-devel, kde-buildsystem, cgiboudeaux, dhaumann, michaelh, 
ngraham, bruns, #frameworks, #build_system

D12672: Use a target in FindDiscount (modern cmake) rather than variables

[Albert Astals Cid]

aacid added a comment.


  If noone disagrees i guess you can commit this in one week or so, i don't 
really have enough knowledge to discuss if this is better or worse.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D12672

To: svuorela, kde-buildsystem
Cc: aacid, #okular, ngraham

D12672: Use a target in FindDiscount (modern cmake) rather than variables

[Albert Astals Cid]

aacid added a comment.


  It's more lines of code than before, what's the improvement?

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D12672

To: svuorela, kde-buildsystem
Cc: aacid, #okular, ngraham

D12120: Check if the application androiddeployqt package has a main() symbol

[Albert Astals Cid]

aacid added a comment.


  Is this going to fail on my translated nm output?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D12120

To: apol, #frameworks, #build_system
Cc: aacid, michaelh, ngraham, bruns

D10166: Add -Wlogical-op -Wzero-as-null-pointer-constant to KF5 warnings

[Albert Astals Cid]

aacid planned changes to this revision.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D10166

To: aacid
Cc: cgiboudeaux, dhaumann, #frameworks, #build_system, michaelh

D10759: Use QLocale instead of QLocale::system

[Albert Astals Cid]

aacid abandoned this revision.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D10759

To: aacid, apol, ilic
Cc: kossebau, apol, #frameworks, #build_system, michaelh, kmorwinski

D10759: Use QLocale instead of QLocale::system

[Albert Astals Cid]

aacid added a comment.


  there's a new revision of D10757  that 
shouldn't need this at all.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10759

To: aacid, apol, ilic
Cc: kossebau, apol, #frameworks, #build_system, michaelh

D10759: Use QLocale instead of QLocale::system

[Albert Astals Cid]

aacid created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.
aacid requested review of this revision.

REVISION SUMMARY
  That makes it work if someone called QLocale::setDefault like kxmlgui does 
when setting an individual app language

TEST PLAN
  See https://bugs.kde.org/show_bug.cgi?id=390623

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10759

AFFECTED FILES
  modules/ECMQmLoader.cpp.in

To: aacid
Cc: #frameworks, #build_system, michaelh

D10166: Add -Wlogical-op -Wzero-as-null-pointer-constant to KF5 warnings

[Albert Astals Cid]

aacid added a comment.


  -Wzero-as-null-pointer-constant does exist here, you're right the other one 
doesn't
  
  I'll try to get this fixed once i recover for the havoc caused by my hd dying

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D10166

To: aacid
Cc: cgiboudeaux, dhaumann, #frameworks, #build_system, michaelh, ngraham

D9793: Fall back to language name for translations lookup if locale name fails

[Albert Astals Cid]

aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9793

To: wbauer, #frameworks, aacid
Cc: aacid, safaalfulaij, #build_system

D9899: Android: Add more includes

[Albert Astals Cid]

aacid created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.
aacid requested review of this revision.

REVISION SUMMARY
  Without this i get
  
  In file included from 
/home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/bits/stl_algo.h:59:0,
  
from 
/home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/algorithm:62,
from 
/home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtCore/qglobal.h:109,
from 
/home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtGui/qtguiglobal.h:43,
from 
/home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/qtwidgetsglobal.h:43,
from 
/home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/qapplication.h:43,
from 
/home/tsdgeos/devel/binaryQt/5.9.2/android_armv7/include/QtWidgets/QApplication:1,
from /home/tsdgeos/devel/kde/ktuberling/main_mobile.cpp:11:
  
  
/home/tsdgeos/Android/Sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/cstdlib:72:20:
 fatal error: stdlib.h: No such file or directory
   #include 
  
^
  
  compilation terminated.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9899

AFFECTED FILES
  toolchain/Android.cmake

To: aacid
Cc: #frameworks, #build_system

D9116: Make sure to search for Qt5-based qmlplugindump

[Albert Astals Cid]

aacid added a comment.


  is this a problem caused by qmlplugindump being one of those magic things 
that are "symlinks" to the qt4 or qt5 depending on the QT_SELECT env var?
  
  maybe makes more sense to fix the execute_process so that it sets QT_SELECT 
to 5?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9116

To: asturmlechner, apol
Cc: aacid, dfaure, cgiboudeaux, #frameworks, #build_system

D9118: ki18n cmake macros: Mark UIC-generated .h files to skip AUTOMOC by default

[Albert Astals Cid]

aacid added a comment.


  Will this cause trouble with older cmake versions?

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D9118

To: mpyne, #frameworks, #build_system, #localization
Cc: aacid

D8173: Use readelf to find project dependencies

[Albert Astals Cid]

aacid added a comment.


  still not working in my setup
  the setenv seems to not be working
  and complains with
  
  - could not find  0x0001 (NEEDED) Shared library: 
[libKF5ConfigCore.so] in /home/tsdgeos/devel/kde/ktuberling/export//lib or 
/home/tsdgeos/devel/kde/ktuberling/build_android
  
  which is true, the library is not in any of those two paths

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8173

To: apol, #frameworks, #build_system, aacid
Cc: mart

D8173: Use readelf to find project dependencies

[Albert Astals Cid]

aacid added a comment.


  In https://phabricator.kde.org/D8173#167776, @apol wrote:
  
  > I either need more information
  
  
  I'm happy to provide any information you want, i just don't know what you 
need other than KConfigCore.so is in the apk without your patch and not with 
your patch.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8173

To: apol, #frameworks, #build_system, aacid
Cc: mart

D8173: Use readelf to find project dependencies

[Albert Astals Cid]

aacid added a comment.


  I'm still not getting libkconfigcore.so into the apk with this

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8173

To: apol, #frameworks, #build_system, aacid
Cc: mart

D8173: Use readelf to find project dependencies

[Albert Astals Cid]

aacid requested changes to this revision.
aacid added a comment.
This revision now requires changes to proceed.


  This breaks KTuberling build for me, libKF5ConfigCore.so is not added to the 
apk anymore.
  
  Two random guesses since i'm not sure i understood the code enough:
  
  - does readelf need to be "the android sdk one" or any readelf works?
  - if readelf is being executed in cmake time isn't that too early since the 
binary (i.e. ktuberling_mobile) doesn't exist yet and you can't readelf it?
  
  Please ignore me if i'm saying stupid stuff :D

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D8173

To: apol, #frameworks, #build_system, aacid

D7198: Set CMAKE_*_OUTPUT_DIRECTORY to run tests without installing.

[Albert Astals Cid]

aacid closed this revision.
aacid added a comment.


  Seems you commited this but forgot to close this?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D7198

To: dfaure, cgiboudeaux, kfunk
Cc: kossebau, aacid, kfunk, #frameworks, #build_system

D7198: Set CMAKE_*_OUTPUT_DIRECTORY to run tests without installing.

[Albert Astals Cid]

aacid added a comment.


  You broke all the builds

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D7198

To: dfaure, cgiboudeaux, kfunk
Cc: aacid, kfunk, #frameworks, #build_system

D7094: Include a module for finding qml imports as runtime dependencies

[Albert Astals Cid]

aacid added a comment.


  Guess it would be useful, i'm 68% sure 
https://bugs.kde.org/show_bug.cgi?id=383065 is because packaging...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D7094

To: apol, #build_system, #frameworks, sitter
Cc: aacid

D6875: Add --gradle to androiddeployqt

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:165465ee7116: Add --gradle to androiddeployqt (authored 
by aacid).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6875?vs=17111=17598

REVISION DETAIL
  https://phabricator.kde.org/D6875

AFFECTED FILES
  toolchain/Android.cmake

To: aacid, apol, kossebau, mart
Cc: #frameworks, #build_system

D6876: Fix install apk target

[Albert Astals Cid]

This revision was automatically updated to reflect the committed changes.
Closed by commit R240:b4f37c8fe172: Fix install apk target (authored by aacid).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D6876?vs=17114=17597

REVISION DETAIL
  https://phabricator.kde.org/D6876

AFFECTED FILES
  toolchain/Android.cmake

To: aacid, apol, mart, kossebau
Cc: #frameworks, #build_system

D6701: Make ECMPoQmToolsTestactually fail if a translation is wrong

[Albert Astals Cid]

aacid added a subscriber: apol.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D6701

To: wbauer, skelly
Cc: apol, #frameworks, #build_system

D6876: Fix install apk target

[Albert Astals Cid]

aacid created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  fix_install_apk

REVISION DETAIL
  https://phabricator.kde.org/D6876

AFFECTED FILES
  toolchain/Android.cmake

To: aacid, apol, mart, kossebau
Cc: #frameworks, #build_system

D6875: Add --gradle to androiddeployqt

[Albert Astals Cid]

aacid created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  Otherwise when trying to build with the newest Qt/android toolchains it fails

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  add_gradle

REVISION DETAIL
  https://phabricator.kde.org/D6875

AFFECTED FILES
  toolchain/Android.cmake

To: aacid, apol, kossebau, mart
Cc: #frameworks, #build_system

D5489: Sanitizers: Don't use GCC-like flags for e.g. MSVC

[Albert Astals Cid]

aacid accepted this revision.
aacid added a comment.
This revision is now accepted and ready to land.


  Makes sense, the other option would be actually erroring out as we do in 
check_compiler_version if you don't run "the correct clang/gcc", but i guess 
this may be enough for MSVC at this point.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5489

To: kfunk, aacid, bcooksley
Cc: #frameworks, #build_system

D5143: Introduce fetch-translations build command

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> KDECMakeSettings.cmake:307
> +math(EXPR idx "${idx}+1")
> +string(SUBSTRING ${reponame} ${idx} -1 reponame)
> +endif()

This only works if you used kde:okular but not 
git://anongit.kde.org/okular.git, no?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D5143

To: apol, #frameworks, #build_system, kfunk, ltoscano, aacid
Cc: sitter

D5143: Introduce fetch-translations build command

[Albert Astals Cid]

aacid added a comment.


  That creates a dependency for ki18n for frameworks that only use .ts files, 
no?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D5143

To: apol, #frameworks, #build_system, kfunk, ltoscano, aacid
Cc: sitter

D5143: Introduce fetch-translations build command

[Albert Astals Cid]

aacid added a comment.


  why find_package(KF5I18n) ?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D5143

To: apol, #frameworks, #build_system, kfunk, ltoscano, aacid
Cc: sitter

D5136: Introduce fetch-translations build command

[Albert Astals Cid]

aacid added a comment.


  I'm not sure addign a dependency for releaseme in ki18n is a good idea to be 
honest.
  
  This very "only works for KDE-based applications", a third-party using k18n 
has no interest in this at all.
  
  Maybe it would make more sense in some of the *KDE* files ECM has?

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D5136

To: apol, #frameworks, #build_system, sitter, kfunk, aacid

[Differential] [Commented On] D4810: ecm_install_po_files_as_qm: filter the .po files

[Albert Astals Cid]

aacid added a comment.


  What's the use case?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D4810

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: ltoscano
Cc: aacid, #frameworks, #build_system

Re: Review Request 128278: Re-use tar macro from kdevplatform. To fix dependent builds reproducibility.

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128278/#review102587
---



This does create a dependency on you having tar installed instead of just 
cmake, maybe that's a problem for the windows people? Has anyone contacted the 
cmake people about making it them adding those switches/functionality? AFAIK 
they're quite open to our requests.

- Albert Astals Cid


On Feb. 9, 2017, 2:40 p.m., Scarlett Clark wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128278/
> ---
> 
> (Updated Feb. 9, 2017, 2:40 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Sune Vuorela and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Cmake tar command does not allow for switches that fix umask and user/group 
> inconsistancy which cause unreproducible builds. This patch takes the tar 
> command used in kdevplatform that has all the required switches to make 
> builds that use this macro reproducible.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEPackageAppTemplates.cmake c0eb8b9 
> 
> Diff: https://git.reviewboard.kde.org/r/128278/diff/
> 
> 
> Testing
> ---
> 
> Build and installed ECM and then rebuilt an affected project ( 
> plasma-framework ) which is now reproducible.
> 
> 
> Thanks,
> 
> Scarlett Clark
> 
>

Re: Review Request 128278: Re-use tar macro from kdevplatform. To fix dependent builds reproducibility.

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128278/#review102385
---



Any reason we ignore .svn and not .git?

- Albert Astals Cid


On June 24, 2016, 1:27 p.m., Scarlett Clark wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128278/
> ---
> 
> (Updated June 24, 2016, 1:27 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Sune Vuorela and Simon Wächter.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Cmake tar command does not allow for switches that fix umask and user/group 
> inconsistancy which cause unreproducible builds. This patch takes the tar 
> command used in kdevplatform that has all the required switches to make 
> builds that use this macro reproducible.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEPackageAppTemplates.cmake c0eb8b9 
> 
> Diff: https://git.reviewboard.kde.org/r/128278/diff/
> 
> 
> Testing
> ---
> 
> Build and installed ECM and then rebuilt an affected project ( 
> plasma-framework ) which is now reproducible.
> 
> 
> Thanks,
> 
> Scarlett Clark
> 
>

Re: Review Request 128779: Teach KDECompilerSettings about clang-cl, a mode of Clang compiler that simulates MSVC.

[Albert Astals Cid]

> On Feb. 4, 2017, 11:05 a.m., Albert Astals Cid wrote:
> > Patch doesn't apply anymore
> 
> Gleb Popov wrote:
> Is there any interest in this?

To be honest I don't even understand what it does from the description :D

What does "simulates MSVC" mean? It compiles windows binaries from linux?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128779/#review102364
---


On Oct. 12, 2016, 11:57 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128779/
> ---
> 
> (Updated Oct. 12, 2016, 11:57 a.m.)
> 
> 
> Review request for Extra Cmake Modules and kdewin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> By simply using `if(CMAKE_COMPILER_ID STREQUAL "Clang")` check is not enough 
> for clang-cl, as it turns on various '-style' flags and omits MSVC's '/style' 
> flags.
> 
> With this patch i managed to compile much of KF5 up to konversation and kate.
> 
> Known problems: `-std=gnu++98` flag is still appended, but i wasn't able to 
> figure out why.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake dfa29f7 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/128779/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 123031: Let Kross be useable w/o searching for private deps

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123031/#review102369
---



This patch does not apply anymore.

- Albert Astals Cid


On May 26, 2015, 8:04 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123031/
> ---
> 
> (Updated May 26, 2015, 8:04 p.m.)
> 
> 
> Review request for Build System, KDE Frameworks and Alex Merry.
> 
> 
> Repository: kross
> 
> 
> Description
> ---
> 
> Only search for public deps in cmake config.
> 
> Open question - shall we search *all* public deps, or minimal ones? e.g. 
> target 1 link Qt5Core, target 2 links Qt5Gui. Do we search for both, or just 
> Qt5Core?
> 
> 
> Diffs
> -
> 
>   KF5KrossConfig.cmake.in e89cee2 
> 
> Diff: https://git.reviewboard.kde.org/r/123031/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Re: Review Request 128779: Teach KDECompilerSettings about clang-cl, a mode of Clang compiler that simulates MSVC.

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128779/#review102364
---



Patch doesn't apply anymore

- Albert Astals Cid


On Oct. 12, 2016, 11:57 a.m., Gleb Popov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128779/
> ---
> 
> (Updated Oct. 12, 2016, 11:57 a.m.)
> 
> 
> Review request for Extra Cmake Modules and kdewin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> By simply using `if(CMAKE_COMPILER_ID STREQUAL "Clang")` check is not enough 
> for clang-cl, as it turns on various '-style' flags and omits MSVC's '/style' 
> flags.
> 
> With this patch i managed to compile much of KF5 up to konversation and kate.
> 
> Known problems: `-std=gnu++98` flag is still appended, but i wasn't able to 
> figure out why.
> 
> 
> Diffs
> -
> 
>   kde-modules/KDECompilerSettings.cmake dfa29f7 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/128779/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gleb Popov
> 
>

Re: Review Request 127440: Revert "ECMQtDeclareLoggingCategory: Include with the generated file"

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127440/#review102226
---



Any reason this was not committed?

- Albert Astals Cid


On March 20, 2016, 6:46 p.m., Stephen Kelly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127440/
> ---
> 
> (Updated March 20, 2016, 6:46 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Alex Merry and Martin Klapetek.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> The original review request doesn't say what concrete problem led to this 
> being added: https://git.reviewboard.kde.org/r/126368/
> 
> 
> QLoggingCategory has always included QDebug, so this has always been 
> superfluous.
> 
> 
> Diffs
> -
> 
>   modules/ECMQtDeclareLoggingCategory.cmake 3f7bb79 
>   modules/ECMQtDeclareLoggingCategory.h.in b59bc7a 
> 
> Diff: https://git.reviewboard.kde.org/r/127440/diff/
> 
> 
> Testing
> ---
> 
> None.
> 
> 
> Thanks,
> 
> Stephen Kelly
> 
>

Re: Review Request 129724: [frameworks] Enable -Wsuggest-override for g++ >= 5.0.0

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129724/
---

(Updated Jan. 23, 2017, 7:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System, KDE Frameworks and Stephen Kelly.


Changes
---

Submitted with commit faeb56f8137d738d1dfbc1fcfbbacd1e8caeb6f0 by Albert Astals 
Cid to branch master.


Repository: extra-cmake-modules


Description
---

Gives a nice warning about something that should be marked as override but isn't


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 

Diff: https://git.reviewboard.kde.org/r/129724/diff/


Testing
---


Thanks,

Albert Astals Cid

Re: kajongg has new dependencies

[Albert Astals Cid]

Sincerely, this is a *very bad* subject, i suggest you resend it again with 
something like

"Need help with Python dependendencies and cmake"

or something that actually has to do with what you're asking about.

Cheers,
  Albert

El dijous, 5 de gener de 2017, a les 9:24:03 CET, Wolfgang Rohdewald va 
escriure:
> master now requires
> 
> Python 3.5
> python3-twisted 16.0
> python3-pyqt5
> python3-pyqt5.qtsvg
> 
> pyqt4, pykde4 and python2 will not be supported anymore
> 
> pykde4 is unmaintained and does not work with kajongg
> anymore, see kde bugs 333683, 370998, 228016, 253123.
> 
> I will make use of python kf5 bindings when they are available.
> 
> with no kde bindings, kajongg still works but its GUI
> has a few options missing like changing language, and
> it might not always behave exactly as a KDE application.
> 
> Now I tried to adapt CMakeLists.txt but this is not complete.
> Maybe somebody with more knowledge about cmake can
> finish this?
> 
> Known open problems:
> - how to require minimum python3.5?
> - how to require minimum twisted 16.0 for python3?
> - eliminate private copy for PyQt5 in cmake-modules
> - the pykde4 cmake module should not be used, or should it?
>   kajongg does not use pykde4 anymore. But  CMakeLists.txt
>   uses some of its cmake macros:
> 
> PYKDE4_INSTALL_PYTHON_FILES
> PYKDE4_ADD_EXECUTABLE

Re: Review Request 129724: [frameworks] Enable -Wsuggest-override for g++ >= 5.0.0

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129724/
---

(Updated Dec. 29, 2016, 11:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and KDE Frameworks.


Changes
---

Submitted with commit d1d637fadd6dad68995d44101250ebbc3307ed0b by Albert Astals 
Cid to branch master.


Repository: extra-cmake-modules


Description
---

Gives a nice warning about something that should be marked as override but isn't


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 

Diff: https://git.reviewboard.kde.org/r/129724/diff/


Testing
---


Thanks,

Albert Astals Cid

Review Request 129724: [frameworks] Enable -Wsuggest-override for g++ >= 5.0.0

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129724/
---

Review request for Build System and KDE Frameworks.


Repository: extra-cmake-modules


Description
---

Gives a nice warning about something that should be marked as override but isn't


Diffs
-

  kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 

Diff: https://git.reviewboard.kde.org/r/129724/diff/


Testing
---


Thanks,

Albert Astals Cid

Re: Review Request 129708: C project also need Clang Sanitizer

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129708/#review101656
---


Ship it!




Maybe you can add a TODO to investigate it for gcc?

- Albert Astals Cid


On Dec. 29, 2016, 2:48 a.m., Leslie Zhai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129708/
> ---
> 
> (Updated Dec. 29, 2016, 2:48 a.m.)
> 
> 
> Review request for Extra Cmake Modules and Alex Merry.
> 
> 
> Bugs: 374195
> http://bugs.kde.org/show_bug.cgi?id=374195
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> So I just added
> 
> ```
> set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${XSAN_COMPILE_FLAGS}" )
> ```
> 
> for C project to use Clang Sanitizer.
> 
> 
> Diffs
> -
> 
>   modules/ECMEnableSanitizers.cmake 9c8a4de 
> 
> Diff: https://git.reviewboard.kde.org/r/129708/diff/
> 
> 
> Testing
> ---
> 
> testcase for Clang Static Analyzer, and also for Clang Sanitizer 
> https://github.com/LLVM-China/clang-analyzer.github.io/tree/master/tests
> 
> ```
> cmake .. -DCMAKE_C_COMPILER=clang   \ 
>  
> -DCMAKE_CXX_COMPILER=clang++   \  
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DCMAKE_BUILD_TYPE=Debug
> ```
> 
> testcase for kcoreaddons and kjs with GNU compiler
> 
> ```
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DKDE_INSTALL_LIBDIR=lib \
>  
> -D_KDE4_DEFAULT_HOME_POSTFIX=4 \  
>  
> -DBUILD_TESTING=ON
> ```
> 
> ```
> cmake .. -DCMAKE_INSTALL_PREFIX=/usr \
>  
> -DECM_ENABLE_SANITIZERS='address;leak;undefined'\ 
>  
> -DKDE_INSTALL_LIBDIR=lib \
>  
> -DBUILD_TESTING=ON
> ```
> 
> 
> Thanks,
> 
> Leslie Zhai
> 
>

Re: Review Request 129708: C project also need Clang Sanitizer

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129708/#review101625
---



I've reverted the change since it was causing compilation problems for anything 
that uses pthreads
https://build.kde.org/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/126/console
https://build.kde.org/job/kjs%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/151/console
https://build.kde.org/job/kstars%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/477/console

I did a 20 minute investigation and the problem is that cmake gets confused 
because somehow -fsanitize defines pthread_create so it thinks it doesn't need 
to add pthread library, but we do. Possible solutions are maybe make cmake 
check a different pthread function, forcing pthread always on if using sanitize 
address, or something smarter i didn't think of.

This would have happened with the C++ variant but it seems cmake checks for the 
need for pthread using the C compiler so that's why we had evaded it for now.

- Albert Astals Cid


On Dec. 28, 2016, 1:56 a.m., Leslie Zhai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129708/
> ---
> 
> (Updated Dec. 28, 2016, 1:56 a.m.)
> 
> 
> Review request for Extra Cmake Modules and Alex Merry.
> 
> 
> Bugs: 374195
> http://bugs.kde.org/show_bug.cgi?id=374195
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> So I just added
> 
> ```
> set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${XSAN_COMPILE_FLAGS}" )
> ```
> 
> for C project to use Clang Sanitizer.
> 
> 
> Diffs
> -
> 
>   modules/ECMEnableSanitizers.cmake 9c8a4de 
> 
> Diff: https://git.reviewboard.kde.org/r/129708/diff/
> 
> 
> Testing
> ---
> 
> testcase for Clang Static Analyzer, and also for Clang Sanitizer 
> https://github.com/LLVM-China/clang-analyzer.github.io/tree/master/tests
> 
> 
> Thanks,
> 
> Leslie Zhai
> 
>

Re: Review Request 129413: KDEPim is not on kde/kdepim repo anymore.

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129413/#review100894
---


Ship it!




Ship It!

- Albert Astals Cid


On Nov. 16, 2016, 11:28 a.m., Tomaz  Canabrava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129413/
> ---
> 
> (Updated Nov. 16, 2016, 11:28 a.m.)
> 
> 
> Review request for Build System.
> 
> 
> Repository: kdesrc-build
> 
> 
> Description
> ---
> 
> Signed-off-by: Tomaz Canabrava <tcanabr...@kde.org>
> 
> 
> Diffs
> -
> 
>   kf5-kdepim-build-include fbf32e1e9be8aa560de631027741a34873df3690 
> 
> Diff: https://git.reviewboard.kde.org/r/129413/diff/
> 
> 
> Testing
> ---
> 
> kdesrc-build --src-only doesn't fails anymore.
> 
> 
> Thanks,
> 
> Tomaz  Canabrava
> 
>

Re: Review Request 129119: Fix HAVE_TRUNC cmake check

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129119/
---

(Updated Oct. 19, 2016, 12:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and kdelibs.


Changes
---

Submitted with commit 0c642ae95dacf894e50630ffcc1961ad1e4e0322 by Albert Astals 
Cid to branch KDE/4.14.


Repository: kdelibs


Description
---

On newer distros the check fails because trunc is ambiguous, so tell sizeof 
exactly which trunc we're speaking about.


Diffs
-

  ConfigureChecks.cmake 2729adb 
  cmake/modules/CheckPrototypeExists.cmake 811d648 

Diff: https://git.reviewboard.kde.org/r/129119/diff/


Testing
---

kdelibs compiles (a bit more, there's still an unrelated issue)


Thanks,

Albert Astals Cid

Review Request 129119: Fix HAVE_TRUNC cmake check

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129119/
---

Review request for Build System and kdelibs.


Repository: kdelibs


Description
---

On newer distros the check fails because trunc is ambiguous, so tell sizeof 
exactly which trunc we're speaking about.


Diffs
-

  ConfigureChecks.cmake 2729adb 
  cmake/modules/CheckPrototypeExists.cmake 811d648 

Diff: https://git.reviewboard.kde.org/r/129119/diff/


Testing
---

kdelibs compiles (a bit more, there's still an unrelated issue)


Thanks,

Albert Astals Cid

Re: Review Request 128823: ecm_process_po_files_as_qm: Skip fuzzy translations

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128823/#review98892
---


Ship it!




Ship It!

- Albert Astals Cid


On Sept. 3, 2016, 7:32 p.m., Alexander Potashev wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128823/
> ---
> 
> (Updated Sept. 3, 2016, 7:32 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Albert Astals Cid and Luigi Toscano.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> ecm_process_po_files_as_qm: Skip fuzzy translations
> 
> 
> Diffs
> -
> 
>   modules/ECMPoQmTools.cmake de275d3201dfdd8ab8874b543b65d3d6fd29eab9 
> 
> Diff: https://git.reviewboard.kde.org/r/128823/diff/
> 
> 
> Testing
> ---
> 
> Built kwidgetsaddons-5.25.0 with old and new version of ECMPoQmTools.cmake, 
> checked presence/absence of Russian translation for string "European Scripts" 
> (it's fuzzy).
> 
> 
> Thanks,
> 
> Alexander Potashev
> 
>

Re: The return of ASAN issues

[Albert Astals Cid]

El dimarts, 31 de maig de 2016, a les 18:49:29 CEST, Ben Cooksley va escriure:
> On Tue, May 31, 2016 at 9:36 AM, Albert Astals Cid <aa...@kde.org> wrote:
> > El dilluns, 30 de maig de 2016, a les 19:42:38 CEST, Ben Cooksley va 
escriure:
> >> Hi all,
> >> 
> >> As you may recall, some time ago the CI scripts were adapted to
> >> forcibly inject ASAN into all test processes launched on the CI system
> >> to fix Marble's tests, as Marble does not use ECM and thus does not
> >> enable ASAN as a result.
> >> 
> >> Unfortunately this has bad effects with certain processes,
> >> particularly Java based ones. This causes the tests of other projects
> >> to fail as a result with segmentation faults, as they're incompatible
> >> with forced ASAN injection - they have to actually be built with ASAN
> >> for it to work.
> >> 
> >> Can someone please investigate another solution?
> > 
> > I know it's a workaround, but given Marble is a bit of an unique snowflake
> > in that it doesn't want to use ECM because it adds 0.3MB of dependencies,
> > can't we just apply the LD_PRELOAD workaround on the "marble" job level
> > (afaik we can do those things)?
> 
> With a maintenance cost. But yes, it could be done.

A very low maitenance cost IMHO compared to your suggestion, half proof is 
that you got someone that volunteered to implement my suggestion (me and i 
think Friedrich volunteered for something similar) while noone volunteered to 
play with the cmake files.

As I see it what you're asking for is more correct but has a much bigger 
coding cost and the solution to applying the workaround only to marble is 
probably a 5 minute change that alls us to move forward.

Cheers,
  Albert

> 
> > What you suggest would be superb correct-ness wise but it doesn't seem the
> > more effort/result solution.
> 
> It would also fix anyone who has compiled Frameworks with ASAN and
> needs to use a build system from elsewhere which does not use ECM
> (Such as QMake for instance, although why you'd use ASAN in Frameworks
> and not your app is another thing altogether of course)
> 
> > Cheers,
> > 
> >   Albert
> 
> Regards,
> Ben
> 
> >> As ASAN is contagious, I would suggest that any Framework which is
> >> compiled using ASAN have adjustments made to it's *Config.cmake files
> >> to ensure linking for any binary/library built with it is setup
> >> properly. I've no idea how complicated that is to setup though.
> >> 
> >> This would fix Marble's tests while allowing Skrooge's tests that
> >> depend on Java to be unaffected (and I considered the original fix to
> >> inject ASAN a bit hackish, so i'm not surprised it's had casualties)
> >> 
> >> Cheers,
> >> Ben
> >> ___
> >> Kde-frameworks-devel mailing list
> >> kde-frameworks-de...@kde.org
> >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> ___
> Kde-frameworks-devel mailing list
> kde-frameworks-de...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: The return of ASAN issues

[Albert Astals Cid]

El dilluns, 30 de maig de 2016, a les 19:42:38 CEST, Ben Cooksley va escriure:
> Hi all,
> 
> As you may recall, some time ago the CI scripts were adapted to
> forcibly inject ASAN into all test processes launched on the CI system
> to fix Marble's tests, as Marble does not use ECM and thus does not
> enable ASAN as a result.
> 
> Unfortunately this has bad effects with certain processes,
> particularly Java based ones. This causes the tests of other projects
> to fail as a result with segmentation faults, as they're incompatible
> with forced ASAN injection - they have to actually be built with ASAN
> for it to work.
> 
> Can someone please investigate another solution?

I know it's a workaround, but given Marble is a bit of an unique snowflake in 
that it doesn't want to use ECM because it adds 0.3MB of dependencies, can't 
we just apply the LD_PRELOAD workaround on the "marble" job level (afaik we 
can do those things)?

What you suggest would be superb correct-ness wise but it doesn't seem the 
more effort/result solution.

Cheers,
  Albert

> 
> As ASAN is contagious, I would suggest that any Framework which is
> compiled using ASAN have adjustments made to it's *Config.cmake files
> to ensure linking for any binary/library built with it is setup
> properly. I've no idea how complicated that is to setup though.
> 
> This would fix Marble's tests while allowing Skrooge's tests that
> depend on Java to be unaffected (and I considered the original fix to
> inject ASAN a bit hackish, so i'm not surprised it's had casualties)
> 
> Cheers,
> Ben
> ___
> Kde-frameworks-devel mailing list
> kde-frameworks-de...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: CMake Error when building attica

[Albert Astals Cid]

Works here, cc'ing the build-system and frameworks lists in case someone gets 
an idea of what may be wrong from the log.

Cheers,
  Albert

El Monday 29 February 2016, a les 22:26:49, Nilesh Kokane va escriure:
> Hello,
> 
> While building attica-5.19.0 cmake threw the following error.
> 
> -- 
> 
> CMake Error at /usr/local/share/ECM/modules/ECMPackageConfigHelpers.cmake:95
> (file):
>   file RELATIVE_PATH must be passed a full path to the file:
> Call Stack (most recent call first):
>   CMakeLists.txt:55 (ecm_configure_package_config_file)
> 
> 
> -- 
> -- The following REQUIRED packages have been found:
> 
>  * ECM (required version >= 5.19.0) , Extra CMake Modules. ,
> 
>  * Qt5Core
>  * Qt5Network
>  * Qt5 (required version >= 5.3.0)
> 
> -- Configuring incomplete, errors occurred!
> See also
> "/home/nilesh/development/lfs/attica-5.19.0/build/CMakeFiles/CMakeOutput.lo
> g". See also
> "/home/nilesh/development/lfs/attica-5.19.0/build/CMakeFiles/CMakeError.log
> ".
> 
> 
> My input switch to cmake is
> 
>   cmake -DCMAKE_INSTALL_PREFIX=$KF5_PREFIX  \
>   -DCMAKE_BUILD_TYPE=Release\
> ..
> 
> $echo $KF5_PREFIX
> /opt/kf5
> 
> 
> But thats not the case with attica-5.18.0 ,it builds successfully.
> I've updated ECM and cmake.
> 
> Am I missing something?
> 
> Please spare me if this is not the rite mailing list for this.
> 
> 
> 
>  Nilesh Kokane

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126183: Add a FindPoppler module to ECM

[Albert Astals Cid]

> On nov. 28, 2015, 6:19 p.m., Alex Merry wrote:
> > I'm happy for this to go in, if the Okular and KBibTex projects are happy 
> > to use it.

>From the Okular side, if it doesn't break anything, i don't care.


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126183/#review88914
---


On nov. 28, 2015, 12:43 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126183/
> ---
> 
> (Updated nov. 28, 2015, 12:43 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Albert Astals Cid and Tobias Koenig.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> At least Okular and KBibTex include a FindPoppler.cmake module but this one
> uses the new ECMFindModuleHelpers and has imported targets.
> 
> ---
> 
> To make FindPoppler.cmake work without pkg-config it also includes this 
> commit:
> 
> 
> Use PATH_SUFFIXES in ecm_find_package_handle_library_components()
> 
> 
> This is required to find poppler without package config as all the headers
> are installed in a poppler subdirectory of the include directory
> 
> 
> Diffs
> -
> 
>   find-modules/FindPoppler.cmake PRE-CREATION 
>   find-modules/FindWayland.cmake c5a56c1635d03acdaf5ccd780b9a358d6f6655fd 
>   modules/ECMFindModuleHelpers.cmake 2044efe1ccf679b738f68aec9b3fb007c449717c 
> 
> Diff: https://git.reviewboard.kde.org/r/126183/diff/
> 
> 
> Testing
> ---
> 
> Okular can be built using this find module with minor changes. As it doesn't 
> set various HAVE_POPPLER_0_36 etc. variables that the find module in okular 
> did, I set those variables in the okular CMakeLists.txt
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 126183: Add a FindPoppler module to ECM

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126183/#review88904
---


Do you have the patch you'd use for okular so we can have a look?

- Albert Astals Cid


On nov. 27, 2015, 12:47 p.m., Alex Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126183/
> ---
> 
> (Updated nov. 27, 2015, 12:47 p.m.)
> 
> 
> Review request for Extra Cmake Modules, Okular, Albert Astals Cid, and Tobias 
> Koenig.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> At least Okular and KBibTex include a FindPoppler.cmake module but this one
> uses the new ECMFindModuleHelpers and has imported targets.
> 
> ---
> 
> To make FindPoppler.cmake work without pkg-config it also includes this 
> commit:
> 
> 
> Use PATH_SUFFIXES in ecm_find_package_handle_library_components()
> 
> 
> This is required to find poppler without package config as all the headers
> are installed in a poppler subdirectory of the include directory
> 
> 
> Diffs
> -
> 
>   find-modules/FindPoppler.cmake PRE-CREATION 
>   modules/ECMFindModuleHelpers.cmake 2044efe1ccf679b738f68aec9b3fb007c449717c 
> 
> Diff: https://git.reviewboard.kde.org/r/126183/diff/
> 
> 
> Testing
> ---
> 
> Okular can be built using this find module with minor changes. As it doesn't 
> set various HAVE_POPPLER_0_36 etc. variables that the find module in okular 
> did, I set those variables in the okular CMakeLists.txt
> 
> 
> Thanks,
> 
> Alex Richardson
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125561: Align FindGettext with CMP002 policy

[Albert Astals Cid]

> On oct. 10, 2015, 9:23 a.m., Albert Astals Cid wrote:
> > This is so much cleaner and easier to understand, what would be a way to 
> > test this, i.e. which tarball do i use that has the problem this is fixing?

i.e. you mention skanlite, but which tarball of it exactly?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86609
---


On oct. 9, 2015, 11:42 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated oct. 9, 2015, 11:42 p.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125561: Align FindGettext with CMP002 policy

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86609
---


This is so much cleaner and easier to understand, what would be a way to test 
this, i.e. which tarball do i use that has the problem this is fixing?

- Albert Astals Cid


On oct. 9, 2015, 11:42 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated oct. 9, 2015, 11:42 p.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125561: Align FindGettext with CMP002 policy

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86629
---

Ship it!


Ship It!

- Albert Astals Cid


On oct. 9, 2015, 11:42 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated oct. 9, 2015, 11:42 p.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


This doesn't look like "a bugfix" to me.

- Albert Astals Cid


On oct. 8, 2015, 5:50 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated oct. 8, 2015, 5:50 p.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Albert Astals Cid]

> On oct. 9, 2015, 8:26 p.m., Albert Astals Cid wrote:
> > This doesn't look like "a bugfix" to me.
> 
> Jeremy Whiting wrote:
> Oh, but it is. Without this or cmake_policy(SET CMP0002 OLD) (see 
> https://bugs.kde.org/show_bug.cgi?id=316308) applications that have their own 
> translations in the tarball (everything we release from extragear) fails to 
> build with a newer cmake. With this change in the kdelibs cmake modules it 
> builds fine by setting a different target for each po folder.

Ok, bad wording, it's probably a bugfix, but doesn't look like a minimal 
bugfix, i mean it's rewriting the whole file, is there nothing better than that 
we can do?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


On oct. 8, 2015, 5:50 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated oct. 8, 2015, 5:50 p.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: broken kdelibs - was- Fwd: Re: KDE Applications 15.08.0 available for packagers

[Albert Astals Cid]

El Dimecres, 19 d'agost de 2015, a les 09:48:17, David Faure va escriure:
 On Wednesday 19 August 2015 00:08:55 Albert Astals Cid wrote:
  Please somebody fix this.
 
 Didn't I just fix that yesterday evening?

You did, I had already sent the email though.

Cheers,
  Albert
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

broken kdelibs - was- Fwd: Re: KDE Applications 15.08.0 available for packagers

[Albert Astals Cid]

Please somebody fix this.

Cheers,
  Albert

--  Missatge reenviat  --

Assumpte: Re: KDE Applications 15.08.0 available for packagers
Data: Dimecres, 19 d'agost de 2015, 00:07:53
De: Albert Astals Cid aa...@kde.org
A: release-t...@kde.org
CC: Antonio Rojas aro...@archlinux.org

El Dimarts, 18 d'agost de 2015, a les 20:18:21, Antonio Rojas va escriure:
 Albert Astals Cid wrote:
  At the usual localtion.
  
  Public release is planned for next week wednesday.
  
  Cheers,
  
Albert
 
 kdelibs fails to build at cmake, with both cmake 3.2.3 and 3.3.1. Lots of
 errors like:
  CMake Error at cmake/modules/KDE4Macros.cmake:926 (add_custom_target):
   add_custom_target cannot create target buildtests because another target
 with the same name already exists.
 
 Full cmake output: https://paste.kde.org/p6qjek1lt
 
 Bisected to commit
 
 https://quickgit.kde.org/?p=kdelibs.gita=commith=ddd2b3290d5d7cef9abfba7ce
 5e15b6c801d531c

I've been told this only happens when not compiling the tests, as a 
workaround, compile the tests.

Cheers,
  Albert

 
 ___
 release-team mailing list
 release-t...@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-t...@kde.org
https://mail.kde.org/mailman/listinfo/release-team
-
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---

(Updated abr. 29, 2015, 11:23 p.m.)


Status
--

This change has been discarded.


Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.


Repository: extra-cmake-modules


Description
---

Do some sanity checking on the dependencies we're declaring


Diffs
-

  modules/ECMGeneratePriFile.cmake af4b877 

Diff: https://git.reviewboard.kde.org/r/123491/diff/


Testing
---

Ran make test in ktextwidgets without 
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
 and it correctly failed.


Thanks,

Albert Astals Cid

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

 On abr. 24, 2015, 3:36 p.m., Alex Merry wrote:
  modules/ECMGeneratePriFile.cmake, lines 178-180
  https://git.reviewboard.kde.org/r/123491/diff/2/?file=362992#file362992line178
 
  I think there should be an argument that could be passed to disable 
  this (NO_TESTS?). Not all downstream users may want such a test.

Why wouldn't you want a test that checks that your .pri is not broken?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79458
---


On abr. 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123491/
 ---
 
 (Updated abr. 24, 2015, 3:26 p.m.)
 
 
 Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Do some sanity checking on the dependencies we're declaring
 
 
 Diffs
 -
 
   modules/ECMGeneratePriFile.cmake af4b877 
 
 Diff: https://git.reviewboard.kde.org/r/123491/diff/
 
 
 Testing
 ---
 
 Ran make test in ktextwidgets without 
 http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
  and it correctly failed.
 
 
 Thanks,
 
 Albert Astals Cid
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

 On abr. 24, 2015, 3:21 p.m., Kevin Funk wrote:
  Hm, this could cause problems in the case where you generate multiple .pri 
  files which depend on each other within one project. Problem .pri files are 
  not yet installed, thus the QT modules are not yet available.
  
  I suggest trying this patch on sonnet, where SonnetUi depends on 
  SonnetCore. Both generate a .pri file, too.
  And if I'm not mistaking I just spotted that the .pri file for SonnetUi 
  doesn't have SonnetCore in its dependency list... = Bug? :)

Aren't basically our tests designed to be run after install?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79454
---


On abr. 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123491/
 ---
 
 (Updated abr. 24, 2015, 3:26 p.m.)
 
 
 Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Do some sanity checking on the dependencies we're declaring
 
 
 Diffs
 -
 
   modules/ECMGeneratePriFile.cmake af4b877 
 
 Diff: https://git.reviewboard.kde.org/r/123491/diff/
 
 
 Testing
 ---
 
 Ran make test in ktextwidgets without 
 http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
  and it correctly failed.
 
 
 Thanks,
 
 Albert Astals Cid
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---

Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.


Repository: extra-cmake-modules


Description
---

Do some sanity checking on the dependencies we're declaring


Diffs
-

  modules/ECMGeneratePriFile.cmake af4b877 

Diff: https://git.reviewboard.kde.org/r/123491/diff/


Testing
---

Ran make test in ktextwidgets without 
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
 and it correctly failed.


Thanks,

Albert Astals Cid

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

 On abr. 24, 2015, 3:49 p.m., Kevin Funk wrote:
  modules/ECMGeneratePriFile.cmake, line 180
  https://git.reviewboard.kde.org/r/123491/diff/2/?file=362992#file362992line180
 
  Just tested the patch myself on sonnet.
  
  The test indeed breaks if sonnet is not installed beforehand. But I 
  agree, that's probably not a big issue since we usually have to install 
  before running `make test`.
  
  Not having the right `QMAKEPATH` set during the test run imposes 
  another burden on the user, however.
  
  What about adding:
  ```
  set_tests_properties(... PROPERTIES
ENVIRONMENT
  QMAKEPATH=${qt_host_data_dir}
  ```
 
 Kevin Funk wrote:
 Err, wrong. I meant `QMAKEPATH=${CMAKE_INSTALL_PREFIX}`. This is the case 
 where it breaks, of course.

don't think we should workaround the user having the wrong environment, we're 
getting the qmake path from another ecm module, so either fix that one or 
accept your env is broken :D


- Albert


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79460
---


On abr. 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123491/
 ---
 
 (Updated abr. 24, 2015, 3:26 p.m.)
 
 
 Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Do some sanity checking on the dependencies we're declaring
 
 
 Diffs
 -
 
   modules/ECMGeneratePriFile.cmake af4b877 
 
 Diff: https://git.reviewboard.kde.org/r/123491/diff/
 
 
 Testing
 ---
 
 Ran make test in ktextwidgets without 
 http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
  and it correctly failed.
 
 
 Thanks,
 
 Albert Astals Cid
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 123491: Add a test that checks the modules we're depending on exist

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---

(Updated abr. 24, 2015, 3:26 p.m.)


Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.


Changes
---

docu and naming


Repository: extra-cmake-modules


Description
---

Do some sanity checking on the dependencies we're declaring


Diffs (updated)
-

  modules/ECMGeneratePriFile.cmake af4b877 

Diff: https://git.reviewboard.kde.org/r/123491/diff/


Testing
---

Ran make test in ktextwidgets without 
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
 and it correctly failed.


Thanks,

Albert Astals Cid

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

What's the use case of KDE_INSTALL_DATADIR vs DATA_INSTALL_DIR

[Albert Astals Cid]

Hi, can somebody please help me understand the need of KDE_INSTALL_DATADIR vs 
DATA_INSTALL_DIR?

http://quickgit.kde.org/?p=blinken.gita=commith=3121f70a7d755b3711c90a4f85f951e23725930d

http://quickgit.kde.org/?p=blinken.gita=blobdiffh=03631e2183bd4f67f398b17eb76b0e59dd35390bhp=362f4e1efe2d3554ffc8bc2f1176d653596d6924hb=3121f70a7d755b3711c90a4f85f951e23725930df=CMakeLists.txt

Thanks :)

Cheers,
  Albert
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: KDE_INSTALL_USE_QT_SYS_PATHS as default

[Albert Astals Cid]

El Dijous, 5 de març de 2015, a les 13:00:50, Aleix Pol va escriure:
 Hi,
 It's been on some occasions already that I've seen reports of people
 trying to get some KDE application installed and complaining (mostly
 the ones based on QML). The reason is that KDE is assuming the
 application is being installed into its own prefix by default.
 
 I've been wondering that maybe we shouldn't? Or maybe we could try to
 detect if it's the same prefix as Qt and in that case install things
 together.
 
 Opinions?

Does the use of KDE_INSTALL_USE_QT_SYS_PATHS imply i need to install as root 
if i'm using the system Qt even if i'm installing the app to my home folder? 

Cheers,
  Albert

 Aleix
 ___
 Kde-frameworks-devel mailing list
 kde-frameworks-de...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 122626: Drop the hacks to find path to lconvert manually

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122626/#review76974
---


That increases the minimum Qt dependency to Qt 5.3.1 for all of the uses here, 
is this something we want? At least it should be documented.

- Albert Astals Cid


On mar. 3, 2015, 11:11 a.m., Dmitry Shachnev wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122626/
 ---
 
 (Updated mar. 3, 2015, 11:11 a.m.)
 
 
 Review request for Build System, Aurélien Gâteau and Harald Sitter.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 The old hacks were not working in some configurations (i.e. when there is 
 `/usr/bin/lconvert` managed by qtchooser, but no qtchooser configuration 
 file).
 
 Qt5LinguistToolsConfig.cmake defines CMake target for `lconvert` since Qt 
 5.3.1, so we can use that instead.
 
 
 Diffs
 -
 
   modules/ECMCreateQmFromPoFiles.cmake 3f134fb 
   modules/ECMPoQmTools.cmake 015b7f9 
 
 Diff: https://git.reviewboard.kde.org/r/122626/diff/
 
 
 Testing
 ---
 
 Build qapt in clean Debian sid chroot. Previously it was failing with 
 qtchooser error, now succeeds.
 
 
 Thanks,
 
 Dmitry Shachnev
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: make uninstall

[Albert Astals Cid]

El Divendres, 30 de gener de 2015, a les 10:47:22, Alex Merry va escriure:
 On Friday 30 January 2015 10:44:23 Alex Merry wrote:
  Over on kde-frameworks-devel, there have been several requests to bring
  back `make uninstall` for KF5 and KF5-based projects.
  
  KDELibs4 used to define this for any dependent projects (it's essentially
  `xargs rm  install_manifest.txt` under the hood), and we could easily add
  it to KDECMakeSettings (with an option to disable it).
 
 We could also easily make it opt-in, either by making a separate module to
 define an uninstall target or by requiring projects or users to set a
 variable/option.

If we know there's people that want it, i guess it's better to make it opt-
out, probably we'll get more homogeinity that way.

Cheers,
  Albert

 
 Alex
 ___
 Kde-buildsystem mailing list
 Kde-buildsystem@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Severe behavioural change regressions in release branch

[Albert Astals Cid]

Hi guys, what's the status of this?

As far as i can see it's still unresolved since kcoreaddons is installing much 
fewer headers than it used to

http://build.kde.org/job/kcoreaddons_master_qt5/153/console
  vs
http://build.kde.org/job/kcoreaddons_master_qt5/152/console

Do you think it's a valid case to autotest?

Cheers,
  Albert

El Divendres, 24 d'octubre de 2014, a les 19:23:42, Ben Boeckel va escriure:
 On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote:
  On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly steve...@gmail.com wrote:
   Is build.kde.org now using the release branch of cmake.git instead of
   the
   next branch? When/why did that change?
  
  This was changed around about
  http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html
  The motivation behind the change was to get the CI system to have the
  same setup as developers I think, and to avoid regressions in 3.1
  which had been causing some build problems at the time. Those same
  regressions are the ones causing us issues now.
  
  Interestingly, the commit which was identified as causing the issue
  occurred back in March, yet this thread was in June. So perhaps there
  may be other commits interacting here (or that was the time when the
  commit previously identified was merged into the next branch).
 
 Earlier this year, I was working on lots of performance metrics of CMake
 and this was part of it. There ended up being more than a dozen branches
 resulting from that work (some of them still unmerged). Doing some
 digging shows that this is where the commit finally hit master:
 
 commit bd20dd6b8a925a421167602027fff9b904fd0822
 Merge: b041fc1 e17a69b
 Author: Brad King brad.k...@kitware.com
 Date:   Thu Jun 12 11:28:44 2014 -0400
 
 so June looks right.
 
 --Ben
 ___
 Kde-frameworks-devel mailing list
 kde-frameworks-de...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: ECM and QNX

[Albert Astals Cid]

El Dijous, 9 d'octubre de 2014, a les 13:59:56, Rafael Roquetto va escriure:
 Hello,
 
 KDECompilerSettings.cmake:176 adds -std=c++0x to CMAKE_CXX_FLAGS for GNU
 compilers. Would it be possible to pass -std=gnu++0x instead?
 
 Rationale:
   The underlying GCC is v4.4, which doesn't know -std=c++11
   yet, only c++0x.
 
   We can't use -std=c++0x here, because the QNX headers
   depend on some GNU extensions (nanosleep() was one that I
   saw), so it has to be gnu++0x, ie. STD C++ + GNU extensions.
 
 
 I am not sure what's the best way to detect a QNX compiler, I am no CMake
 expert.

See modules/ECMEnableSanitizers.cmake you can always check for the compiler 
version like done there, no?

Cheers,
  Albert

 
 Thanks,
 Rafael

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: Review Request 120118: Make code coverage possible in any KDE project

[Albert Astals Cid]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120118/#review66210
---

Ship it!


Looks good to me!

- Albert Astals Cid


On set. 10, 2014, 11:33 p.m., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120118/
 ---
 
 (Updated set. 10, 2014, 11:33 p.m.)
 
 
 Review request for Build System and KDE Frameworks.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 Introduces a BUILD_COVERAGE option in the KDECompilerSettings file so that we 
 can easily enable it from the jenkins installations, and in case somebody 
 wants to do it locally, then too.
 
 
 Diffs
 -
 
   kde-modules/KDECompilerSettings.cmake f0d1aef 
   modules/ECMCoverageOption.cmake PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/120118/diff/
 
 
 Testing
 ---
 
 Plasma Framework is already doing it, I just moved the code.
 
 
 Thanks,
 
 Aleix Pol Gonzalez
 


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem