ich, to my knowledge, is not widely known, and may give
some people trouble when dealing with applications (like CMake) that make use
of environment variables that contain references to other environment variables.
Are we arguing over semantics here?
-Chris
-Original Message-
From: David C
I have been using CMake to build a few open-source projects recently, and I've
been experimenting and moving around build directories and such. In a small
test application, CMake tries to find a library that I built and installed in
one place, and then I rebuilt and installed somewhere else. Mea
the type of an env
var, since the Windows GUI doesn’t even indicate that there are two types.
-Chris
From: Andrew Maclean [mailto:andrew.amacl...@gmail.com]
Sent: Tuesday, August 12, 2014 6:57 PM
To: cmake@cmake.org; Chris Volpe ARA/SED; lucas.pet...@engilitycorp.com
Subject: Re: [CMake
---Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman
Sent: Tuesday, August 12, 2014 3:50 PM
To: cmake@cmake.org
Subject: Re: [CMake] Possible bug in environment variable expansion?
On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote:
> That's a good tho
everything in my path is now "hard coded", so
to speak. Ugh.
So, basically, something is messed up in my system.
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Volpe ARA/SED
Sent: Tuesday, August 12, 2014 12:44 PM
To: lucas.pet...@engilitycorp.com; cmake@cmake.org
Subj
lucas.pet...@engilitycorp.com [mailto:lucas.pet...@engilitycorp.com]
Sent: Monday, August 11, 2014 11:03 PM
To: Chris Volpe ARA/SED; cmake@cmake.org
Subject: RE: Possible bug in environment variable expansion?
Could it be something as simple as UNIX (slash /) vs Windows (backslash \) in
the
I am trying to build an Open Source project called PCL which uses Boost, and
CMake's ability to find the Boost libraries seems dependent on whether the
BOOST_LIBRARYDIR contains a literal path string, or whether it contains a
string that incorporates the expansion of BOOST_ROOT. Here are the det
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are general
suggestions, or if they actually address the problem I'm experiencing.
Moreover, the problems that your suggestions claim to solve seem to be problems
that I am not experiencing.
For example, you write:
After be
> You might break this transitivity by explicitly setting
> the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to ""
That did it Thanks, Michael. That's exactly what I needed.
It's somewhat moot now, but your second suggestion confused me, and I'd like to
understand better:
>
un CMake (a pain).
I'm amazed that nobody has ever experienced this problem before. It seems like
a very natural thing to want to do.
Thanks for the quick response.
-Chris
From: Jean-Christophe Fillion-Robin [mailto:jchris.filli...@kitware.com]
Sent: Tuesday, March 22, 2011 2:41 PM
To: Chris V
I posted this question in the VTK Users mailing list originally, but have since
determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a MSVC++
.sln file that contains the
11 matches
Mail list logo
