On Wed, Nov 14, 2018 at 10:54 AM Sean McBride wrote:
> I see. Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot
> "RogueResearch12" and indeed it does not have a /usr/include folder. It is
> however able to build CMake, VTK, and ITK nightly without any compiler errors.
>
> Perhaps it's n
Le mer. 14 nov. 2018 à 13:25, Poughon Victor a
écrit :
> Yes you are correct on all your observations. We already use ninja and
> ccache wherever we can. In fact we have an issue about the whole end-to-end
> build performance where we track all effort on this throughout the project
> (if you're i
On Wed, 14 Nov 2018 10:43:28 -0600, Steven Stallion said:
>We first noticed that some sources would fail to find certain system
>headers (stddef.h in this case) when using Xcode 10 (also seen on
>Xcode 10.1). It looks like Apple decided to relocate system include
>paths under /Library /Developer a
The way you proceed is wrong.
The system configuration is determined during the 'project' function call.
Setting information after this call is useless. So, in your example, on a
64bit system, the compilation configuration will be 64bit (variable
CMAKE_SIZEOF_VOID_P has value 8).
This explain why '
On Wed, Nov 14, 2018 at 8:19 AM Sean McBride wrote:
> Could you elaborate? What odd behaviour are you seeing? Any error message
> to share? What 'workaround package' are you speaking of? What version of
> Xcode?
We first noticed that some sources would fail to find certain system
headers (
On Tue, 13 Nov 2018 18:42:43 -0600, Steven Stallion said:
>It appears there have been some changes to how macOS handles the
>system include path starting with macOS Mojave. It looks like Apple
>has provided a workaround package you can install to re-instate the
>/usr/include hierarchy, however I w
Hi,
My system is 64 bits but I can cross compile python c modules for 32 bits .
Unfortunately I don't manage to retrieve python 32 libs , always the 64
bits version is found.
here is what I tried :
cmake_minimum_required(VERSION 3.10)
project(py_autom)
set(CMAKE_SYSTEM_PROCESSOR "i686")
Yes you are correct on all your observations. We already use ninja and ccache
wherever we can. In fact we have an issue about the whole end-to-end build
performance where we track all effort on this throughout the project (if you're
interested: https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/i
Le mer. 14 nov. 2018 à 12:06, Poughon Victor a
écrit :
> Thanks for the replies
>
>
>
> You can see configure times on our dashboard (switch to advanced view):
> https://dash.orfeo-toolbox.org/index.php?project=OTB
>
> It ranges from 1-3min. There's even one windows machine that's at 4m30s.
>
So
Thanks for the replies
You can see configure times on our dashboard (switch to advanced view):
https://dash.orfeo-toolbox.org/index.php?project=OTB
It ranges from 1-3min. There's even one windows machine that's at 4m30s.
Thanks for the tip about Ninja generator, it's indeed much faster. But
swi
On Wed, Nov 14, 2018 at 10:20 AM Poughon Victor
wrote:
> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure step needs to
Hi Victor,
Le mer. 14 nov. 2018 à 10:20, Poughon Victor a
écrit :
> Hi all
>
> I am working on a large C++ project using CMake (
> https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a
> lot of time. This can be annoying for developers working on features where
> the configure s
Hi all
I am working on a large C++ project using CMake
(https://www.orfeo-toolbox.org/) and our 'configure' step takes quite a lot of
time. This can be annoying for developers working on features where the
configure step needs to be re-run, or for CI in general.
We have looked into it a bit a
13 matches
Mail list logo
