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-requ...@cmake.org> wrote: > Send CMake mailing list submissions to > cmake@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-requ...@cmake.org > > You can reach the person managing the list at > cmake-ow...@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" <fmil...@sjm.com> > To: CMake MailingList <cmake@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 <cvo...@ara.com> > To: Chris Volpe ARA/SED <cvo...@ara.com>, "lucas.pet...@engilitycorp.com" > <lucas.pet...@engilitycorp.com>, "cmake@cmake.org" <cmake@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-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 > *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.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 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.pet...@engilitycorp.com > ------------------------------ > > *From:* CMake [cmake-boun...@cmake.org] on behalf of Chris Volpe ARA/SED [ > cvo...@ara.com] > *Sent:* Monday, August 11, 2014 6:25 PM > *To:* cmake@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@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 ___________________________________________
-- 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