rjvbb added a comment.
That's because of the MSVC remarks you made inline?
I don't have a way to test with MSVC, so I could do with some suggestions how
to resolve the flagged issues.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5865
To: rjvbb, #
kfunk requested changes to this revision.
This revision now requires changes to proceed.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5865
To: rjvbb, #frameworks, #build_system, cgilles, kfunk
Cc: thiago, kfunk, michaelh, ngraham
rjvbb edited the summary of this revision.
rjvbb edited the test plan for this revision.
rjvbb set the repository for this revision to R240 Extra CMake Modules.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5865
To: rjvbb, #frameworks, #build_system, cgille
rjvbb updated this revision to Diff 14971.
rjvbb added a comment.
Updated as requested.
GIven the controversy I thought it might be useful to add at least a
target-specific enabler macro (which may need some polishing or simplification
- using generator expressions may not be required he
kfunk added a comment.
In https://phabricator.kde.org/D5865#112766, @rjvbb wrote:
> KDE is FOSS not bound to Microsoft by any corporate buy-in or whatever,
right?
What non-sense is this? Please stay on topic. There's a benefit we make sure
KDE software is compiling under MSVC giv
rjvbb added a comment.
KDE is FOSS not bound to Microsoft by any corporate buy-in or whatever, right?
If there's a bug to report it's the lack of standard compliance in MSVC - how
have MS reacted to such reports?
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricato
thiago added a comment.
In https://phabricator.kde.org/D5865#112747, @rjvbb wrote:
> In https://phabricator.kde.org/D5865#112743, @thiago wrote:
>
> > Fix the source code.
> >
> > If certain third-party libraries can't compile under MSVC 2015 (or even
2017!) with default compiler
rjvbb added a comment.
In https://phabricator.kde.org/D5865#112743, @thiago wrote:
> Fix the source code.
>
> If certain third-party libraries can't compile under MSVC 2015 (or even
2017!) with default compiler options, they don't deserve to be used. Blacklist
them.
That may
thiago added a comment.
In https://phabricator.kde.org/D5865#112737, @rjvbb wrote:
> In https://phabricator.kde.org/D5865#112697, @thiago wrote:
>
> > Why are we spending time in named operators? It's much easier to fix the
source code not to use them and then the problem goes away.
rjvbb added a comment.
In https://phabricator.kde.org/D5865#112697, @thiago wrote:
> Why are we spending time in named operators? It's much easier to fix the
source code not to use them and then the problem goes away.
This is about adding a convenience macro for projects that have
thiago added a comment.
In https://phabricator.kde.org/D5865#112679, @rjvbb wrote:
> > That option only exists in MSVC 2017.
>
> Should we have deduce that from the docs I cite in the CMake comments? I'm
willing to believe that I misread as far as support for named operators is
conce
rjvbb added a comment.
> That option only exists in MSVC 2017.
Should we have deduce that from the docs I cite in the CMake comments? I'm
willing to believe that I misread as far as support for named operators is
concerned, but they do mention 2015 Update 3 specifically as the appearance
thiago added a comment.
In https://phabricator.kde.org/D5865#112549, @rjvbb wrote:
> If a compiler is problematic in general it may not be worth it trying to
account for it in a macro, trying to coerce it into doing something it cannot
handle. I don't think that's a reason not to impleme
rjvbb marked an inline comment as done.
rjvbb added a comment.
So, how do we proceed?
When I asked other devs what compiler they used to build their MSWin bundles
they all (both) said they can't use MSVC anyway because it's too buggy.
If a compiler is problematic in general it may no
kfunk requested changes to this revision.
kfunk added a comment.
This revision now requires changes to proceed.
Can't go in as-is, as it breaks compilation on MSVC 2015.
But interesting to see that `/Za` is actually problematic. Which proves my
point: Just don't use named operators in cod
rjvbb added a comment.
ping?
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5865
To: rjvbb, #frameworks, #build_system, cgilles
Cc: kfunk
rjvbb set the repository for this revision to R240 Extra CMake Modules.
REPOSITORY
R240 Extra CMake Modules
REVISION DETAIL
https://phabricator.kde.org/D5865
To: rjvbb, #frameworks, #build_system, cgilles
Cc: kfunk
rjvbb updated this revision to Diff 14635.
rjvbb marked an inline comment as done.
rjvbb added a comment.
This update hopefully introduces the appropriate check for MSVC 2015 update 3
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D5865?vs=14548&id=14635
REVISION DETAIL
https://pha
rjvbb marked an inline comment as done.
rjvbb added a comment.
> I'll hope to find some time to test on Window, wouldn't want this to be
merged before that.
Should we read "not to be merged before *you* have tested it"? I have nothing
against that, esp. if you also find the exact value t
kfunk added a comment.
LGTM in general. I'll hope to find some time to test on Window, wouldn't want
this to be merged before that.
INLINE COMMENTS
> KDECompilerSettings.cmake:226
> +if (MSVC)
> +if (${MSVC_VERSION} GREATER 1900)
> +# /permissive- became the preferred
rjvbb created this revision.
Restricted Application added projects: Frameworks, Build System.
REVISION SUMMARY
A recent commit disabled support for named (logical) operators (and, not,
bitand, &c) when using GCC, Clang or ICC.
This patch adds a function to (re)enable them in a cross-platform
21 matches
Mail list logo
