El 13/07/16 a las 03:21, Chaos Zhang escribió:
Thanks for your references Decker, the condition is it cost close to three
times time after i use CMake than already exist makefile to build project.
And i found the CPU didn't use effectively than exist make flow, so i
wonder if CMake provide s
I'm going to ask two questions, but a good answer to the first will make the
second question redundant.
I work with several different cmake projects that are cross compiled, and they
depend on each other. Each project creates a cmake config, so we can use
find_package to find the contents. Up
On 7/12/16, Harry Mallon wrote:
> Hello all,
>
> What is the current best practice for code signing OSX .apps and binaries? I
> am using:
>
> 1. MAC_OSX_BUNDLE for my .app targets.
> 2. unix style executables
> 3. dylibs
> 4. A prefpane (which I haven't got working yet) using something like the
>
Yes, it was add_subirectory.
I tried once more after cleaning up the CMakeList.txt and now it
worksI must have ad some spurious settings generating the error.
Thanks,
Michele
Le 13/07/2016 à 22:48, Alexander Neundorf a écrit :
On Tuesday 12 July 2016 09:00:43 portolan wrote:
Hello,
Should this have changed in 3.6 I couldn't see anything in the change log?
How can I control where they are generated?
On Fri, 15 Jul 2016, 18:51 David Callu wrote:
> Hi Tom,
>
> Same thing on my side. I call in my code functions defined in generated
> .cpp from moc/rcc.
> Functions name are ba
Hi Tom,
Same thing on my side. I call in my code functions defined in generated
.cpp from moc/rcc.
Functions name are based on file path used during .cpp generation.
And this path change from cmake 3.5 to 3.6.
You should check functions in generated .cpp files that you used in your
code.
HTH
Dav
