All,
I'm currently working on a fairly large project that requires a number of
external tools be installed. I've been playing with the idea of having
CMake download and install these packages prior to building the project. I
have something that works using a combination of custom modules and
(Apologies for the self-reply)
s/CMAKE_CURRENT_BUILD_DIR/CMAKE_CURRENT_BINARY_DIR/
On Tue, Apr 7, 2015 at 12:59 PM, Steven Stallion sstall...@gmail.com
wrote:
All,
I'm currently working on a fairly large project that requires a number of
external tools be installed. I've been playing
A selfish request: would it be possible to slip this into the 3.5
release? This is something that I (and the company I work for) are
very interested in, and I would like to avoid pulling a fork into our
workstream.
Cheers,
Steve
On Mon, Feb 1, 2016 at 8:47 AM, Gilles Khouzam
gt; cleaner now as a bonus.
>
> I tend to blame the time not on file IO, but on time to parse those files.
> I've never done actual profiling though.
>
> -Original Message-
> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Steven Stallion
> Sent: Tuesday,
All,
I am currently working on a very large project that contains over 500
(yes, really) listfiles. A co-worker was looking into some performance
issues we were seeing during configuration and found something very
interesting. Currently configuration is taking 1m57s across several
configurations
All,
I currently have a set of packages defined as ExternalProjects and
packaged up with CPack. I've noticed recently that the preinstall step
has begun failing for a given package and after a little digging, I've
realized that I've likely been using CPack incorrectly for years.
So, rather than
Indeed. Our CMake build here is spread across >500 list files with
around 1G of source code. I've often wondered how it compared to other
large C and assembly projects. To wit, several of the practices in the
article we've followed as well. It's great to hear that someone is
working on a book -
Nice Job! I've spent an inordinate amount of time helping folks come
up to speed on some of the darker corners of CMake the last few years
and it's great to have something to point to rather than my
hodge-podge of collected notes.
On Tue, Jul 10, 2018 at 8:11 AM, Craig Scott wrote:
> Hi all,
All,
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 was wondering if this is something
that could be handled
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 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
11 matches
Mail list logo
