[CMake] Possible bug in environment variable expansion?

Tue Aug 12 18:57:23 EDT 2014

I only define:
BOOST_ROOT=C:\local\boost_1_56_0
BOOST_LIBRARYDIR=C:\local\boost_1_56_0\lib64-msvc-12.0
and this works Ok.

This will not work:
BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0

If you go to a command prompt and type "set" you will see that %BOOST_ROOT%
is not expanded.

So this is a Windows issue, not a CMake issue.

The only clue I have is that Microsoft expands these variables in order and
since BOOST_ROOT is ordered after BOOST_LIBRARYDIR the expansion does not
happen.

Regards
   Andrew

On Wed, Aug 13, 2014 at 5:37 AM, <cmake-request at cmake.org> wrote:

> Send CMake mailing list submissions to
>         cmake at cmake.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://public.kitware.com/mailman/listinfo/cmake
> or, via email, send a message with subject or body 'help' to
>         cmake-request at cmake.org
>
> You can reach the person managing the list at
>         cmake-owner at cmake.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of CMake digest..."
>
> Today's Topics:
>
>    1. Windows RC files with Ninja (Miller, Frank)
>    2. Re: Possible bug in environment variable expansion?
>       (Chris Volpe ARA/SED)
>
>
> ---------- Forwarded message ----------
> From: "Miller, Frank" <FMiller at sjm.com>
> To: CMake MailingList <cmake at cmake.org>
> Cc:
> Date: Tue, 12 Aug 2014 16:44:03 +0000
> Subject: [CMake] Windows RC files with Ninja
> Greetings,
>
> I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with
> RC files. Looks like a simple problem but I would be baffled if I'm the
> first to experience this so I expect I have some kind of configuration
> issue. Here is the offending snippet in the rules.ninja file:
>
> rule RC_COMPILER
>   depfile = $DEP_FILE
>   deps = gcc
>   command = "" RC $in "$DEP_FILE" $out "" "c:/Program Files
> (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe"
> c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe  $FLAGS $DEFINES /fo$out $in
>   description = Building RC object $out
>
> If I put the path to "cmcldeps.exe" in the empty quotes on the command
> line, it works as expected.
>
> Does anyone else have this problem?
>
> Frank
>
> This communication, including any attachments, may contain information
> that is proprietary, privileged, confidential or legally exempt from
> disclosure. If you are not a named addressee, you are hereby notified that
> you are not authorized to read, print, retain a copy of or disseminate any
> portion of this communication without the consent of the sender and that
> doing so may be unlawful. If you have received this communication in error,
> please immediately notify the sender via return e-mail and delete it from
> your system. In order to safeguard its employee data as well as sensitive
> patient, customer, business, legal and other information, the company uses
> all lawful means, under all applicable law, to access, monitor, preserve,
> collect and review all communications between employees and all other users
> only when, and to the extent necessary, to fulfill investigatory and other
> important business and legal responsibilities. By responding to this
> communication, or initiating additional communication with the company, you
> consent to such lawful monitoring, to the extent such consent is required
> and valid in your local area.
>
>
>
> ---------- Forwarded message ----------
> From: Chris Volpe ARA/SED <cvolpe at ara.com>
> To: Chris Volpe ARA/SED <cvolpe at ara.com>, "Lucas.Pettey at engilitycorp.com"
> <Lucas.Pettey at engilitycorp.com>, "cmake at cmake.org" <cmake at cmake.org>
> Cc:
> Date: Tue, 12 Aug 2014 19:37:47 +0000
> Subject: Re: [CMake] Possible bug in environment variable expansion?
>
> As it turns out, something weirder is going on, and it’s not cmake’s
> fault, so I won’t look for a solution here, but I’ll describe the problem
> in case anyone’s interested. **Windows** is not expanding those
> environment variables. First, I hacked up the installed version of
> FindBoost.cmake to spit out some debugging information, with the following,
> circa line 860:
>
>
>
>   message(DEBUG "_ENV_BOOST_LIBRARYDIR has value
> <${_ENV_BOOST_LIBRARYDIR}>")
>
>
>
> and then I ran configure in debug mode, which gave me the following from
> my extra hacked debugging output:
>
>
>
> DEBUG_ENV_BOOST_LIBRARYDIR has value <%BOOST_ROOT%/lib64-msvc-12.0>
>
>
>
> So, when cmake asked the OS for the BOOST_LIBRARYDIR environment variable,
> the OS gave it the string without expanding BOOST_ROOT. I have verified
> this OS behavior by opening up a command window and using the set command:
> It’s not getting expanded. I’ve verified (with RapidEE) that the
> environment variables in question are of type “expandable string”, not
> “string”.
>
>
>
> While playing with the variables in RapidEE (a wonderful tool, BTW), I
> noticed two other strange things. First, I do have a couple of env vars
> that do have other env var references in them, and they **do** get
> expanded in cmd.exe. Second, my PATH env var used to have embedded env vars
> for various things, but somewhere along the way they all got replaced in
> the PATH **definition** with their expanded versions, so now 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-bounces at cmake.org] *On Behalf Of *Chris Volpe
> ARA/SED
> *Sent:* Tuesday, August 12, 2014 12:44 PM
> *To:* Lucas.Pettey at engilitycorp.com; cmake at cmake.org
> *Subject:* Re: [CMake] Possible bug in environment variable expansion?
>
>
>
> That’s a good thought, but unfortunately it didn’t pan out. I tried both
> styles, and I even tried explicitly mixing styles like this:
>
>
>
> BOOST_LIBRARYDIR=C:/local/boost_1_55_0\lib64-msvc-12.0
>
>
>
> Or this:
>
>
>
> BOOST_LIBRARYDIR=C:\local\boost_1_55_0/lib64-msvc-12.0
>
>
>
> And those worked fine.
>
>
>
> *From:* Lucas.Pettey at engilitycorp.com [mailto:
> Lucas.Pettey at engilitycorp.com]
> *Sent:* Monday, August 11, 2014 11:03 PM
> *To:* Chris Volpe ARA/SED; cmake at cmake.org
> *Subject:* RE: Possible bug in environment variable expansion?
>
>
>
> Could it be something as simple as UNIX (slash /) vs Windows (backslash \)
> in the directory expression?
>
>
>
> When this environment variable is expanded BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0,
> it looks like it is converting the %BOOST_ROOT% in UNIX style and then the
> "\lib-msvc-12.0" is Windows. This mixture of styles may be causing a "no
> such directory" system error. I know on Windows systems I need to be
> consistent with directory styles or it fails.
>
>
>
> Lucas Pettey, PhD
>
> HPCMP PETTT EQM CTA Lead
>
> ERDC-DSRC OnSite
>
> Vicksburg, MS
>
> 512-297-9833 Mobile (preferred)
>
> 601-634-2980 Office
>
> lucas.pettey at engilitycorp.com
>    ------------------------------
>
> *From:* CMake [cmake-bounces at cmake.org] on behalf of Chris Volpe ARA/SED [
> cvolpe at ara.com]
> *Sent:* Monday, August 11, 2014 6:25 PM
> *To:* cmake at cmake.org
> *Subject:* [CMake] Possible bug in environment variable expansion?
>
> 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
> details:
>
>
>
> Boost is installed from a pre-built installer in the folder
> C:\local\boost_1_55_0. This folder contains, among other things, a
> subfolder called “boost”, which contains the headers, and a subfolder
> called “lib64-msvc-12.0”, which contains 64-bit libraries built with MS
> Visual Studio 2013. Ordinarily, CMake would like that folder to be called
> simply “lib”, but that’s not what the installer created, so I’m trying to
> override the default with environment variables. I have the following three
> environment variables defined, all of which are of type “Expandable string”:
>
>
>
> BOOST_ROOT=C:\local\boost_1_55_0
>
> BOOST_INCLUDEDIR=%BOOST_ROOT%
>
> BOOST_LIBRARYDIR=%BOOST_ROOT%\lib64-msvc-12.0
>
>
>
> With these settings, CMake reports an error during the configuration
> process, as follows:
>
>
>
> CMake Error at C:/Program Files
> (x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:1179 (message):
> Unable to find the requested Boost libraries.
>
> Boost version: 1.55.0
>
> Boost include path: C:/local/boost_1_55_0
>
> Could not find the following Boost libraries:
>
> boost_system
> boost_filesystem
> boost_thread
> boost_date_time
> boost_iostreams
> boost_chrono
>
> No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
> directory containing Boost libraries or BOOST_ROOT to the location of
> Boost.
> Call Stack (most recent call first):
> cmake/pcl_find_boost.cmake:38 (find_package)
> CMakeLists.txt:230 (include)
>
>
>
> But if change the definition of BOOST_LIBRARYDIR by replacing
> “%BOOST_ROOT%” with the value assigned to BOOST_ROOT, resulting in this:
>
> BOOST_LIBRARYDIR=C:\local\boost_1_55_0\lib64-msvc-12.0
>
> the configuration succeeds. The only difference seems to be whether the
> “C:\local\boost_1_55_0” part of the path is specified explicitly, or
> obtained implicitly with %BOOST_ROOT%. It would surprise me if this
> behavior were by design. Does anyone have an explanation for this?
>
>
>
> Thanks,
>
> Chris
>
>
>
>
>
> *Christopher R. Volpe, Ph.D.*
>
> *Senior Scientist, Remote Sensing & Decision Analytics*
>
>
>
> [image: Description: Description: Description:
> cid:image003.png at 01CE888B.0167BAD0]
>
> *NATIONAL SECURITY**  | ** INFRASTRUCTURE ** |  **ENERGY & ENVIRONMENT *
> * |**  HEALTH SOLUTIONS*
>
> Applied Research Associates, Inc.
>
> 8537 Six Forks Road, Suite 600, Raleigh, NC 27615  |  *T *919.582.3380  |
> *F* 919.582.3301
>
>
>
> *Find Us Online*
>
> www.ara.com
>
> Facebook: Applied Research Associates
> <https://www.facebook.com/#!/AppliedResearchAssociates>
>
> LinkedIn: Company Page <http://www.linkedin.com/company/8853?trk=tyah>
>
> LinkedIn Group
> <http://www.linkedin.com/groups/ARA-Employees-Group-4854334?trk=myg_ugrp_ovr>
>
> Twitter: ARA News <https://twitter.com/ARA_News_Events>
>
> YouTube:  Applied Research Associates
> <http://www.youtube.com/user/AppliedResearch1?feature=mhee>
>
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140813/cbe53742/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9687 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140813/cbe53742/attachment-0001.png>