Non-Vc builds broken (Re: [krita] /: Update krita to compile against Vc >= 1.0.0)

[Boudewijn Rempt]

Making the build work without Vc was too tricky for me, which blocks building
Krita on Windows with MSVC. While I'm working to setup a mingw-build system on
Windows, I've moved the Vc code to a new branch:

rempt-port-vc

Where we should work to fix building without Vc. In the meantime, I've reverted
everything in master, so CI and Windows users can at least build again.

Also note this bug report:

https://bugs.kde.org/show_bug.cgi?id=361546

"The brushes have become really slow in recent 3.0 alpha builds compared to their 2.9 counterparts"

On Fri, 8 Apr 2016, Friedrich W. H. Kossebau wrote:

> Hi Thorsten,
>
> seems this breaks non-Vc builds of Krita (to be seen on CI, which still has Vc
> 0.7.4 and thus tries to build without), e.g.
>
> https://build.kde.org/job/krita%20master%20kf5-qt5/
> PLATFORM=Linux,compiler=gcc/63/
>
> Making Vc a hard dep would long-term be perhaps the best, but for now Vc 1.0
> is not that spread yet, so would put extra burdens to new contributors (&
> distributors).
>
> See below for one thing I found already.
>
> Am Donnerstag, 7. April 2016, 12:56:24 CEST schrieb Thorsten Zachmann:
>> Git commit b68c1c7666510e268babc4cd87cd9d5ad34ff2d5 by Thorsten Zachmann.
>> Committed on 07/04/2016 at 12:54.
>> Pushed by zachmann into branch 'master'.
>>
>> Update krita to compile against Vc >= 1.0.0
>>
>
> <snip>
>
>> diff --git a/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h
>> b/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h index
>> 09677a6..2b10257 100644
>> --- a/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h
>> +++ b/libs/pigment/compositeops/KoVcMultiArchBuildSupport.h
>> @@ -35,6 +35,7 @@
>>  #pragma warning ( disable : 4244 )
>>  #pragma warning ( disable : 4800 )
>>  #endif
>> +#include <Vc/global.h>
>>  #include <Vc/Vc>
>>  #include <Vc/support.h>
>>  #if defined _MSC_VER
>> @@ -44,11 +45,9 @@
>>  #else /* HAVE_VC */
>>
>>  namespace Vc {
>> -    typedef enum {ScalarImpl} Implementation;
>> +    typedef enum {ScalarImpl} CurrentImplementation;
>>  }
>
> There still is Vc::Implementation in the code, so should this here be not a
> change Implementation->CurrentImplementation, but rather an addition of
> CurrentImplementation?
>
> There is also Vc::CurrentImplementation::current() in the general code, so the
> typedef might not be the working solution.
>
> Cheers
> Friedrich
>

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org