Re: [CMake] Possible bug in environment variable expansion?

[Chris Volpe ARA/SED]

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

[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
LinkedIn: Company Page
LinkedIn 
Group
Twitter: ARA News
YouTube:  Applied Research 
Associates



-- 

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://publ

Re: [CMake] Possible bug in environment variable expansion?

[Chris Volpe ARA/SED]

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<mailto: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_fi

Re: [CMake] Possible bug in environment variable expansion?

[Bill Hoffman]

On 8/12/2014 12:44 PM, Chris Volpe ARA/SED wrote:

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

Try setting Boost_DEBUG=1 in your CMake run, and then it should show you 
where it is searching and the problem may become more obvious.


-Bill

--

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

Re: [CMake] Possible bug in environment variable expansion?

[Chris Volpe ARA/SED]

Thanks, Bill. As it turns out, the problem appears to be a bug in Windows. 
Through experimentation, I have determined a truth about environment variables 
that I have yet to be able to find spelled out anywhere: If the type of an 
environment variable does not *need* to be "Expandable String", then it 
*mustn't* be "Expandable String". Environment variable expansion (including 
nested multiple levels) works only when all the variables that reference others 
are of type "Expandable String", and the ones that don't are of type "String". 

-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 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
>
Try setting Boost_DEBUG=1 in your CMake run, and then it should show you where 
it is searching and the problem may become more obvious.

-Bill

-- 

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
-- 

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

Re: [CMake] Possible bug in environment variable expansion?

[Andrew Maclean]

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,  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" 
> To: CMake MailingList 
> Cc:
> Date: Tue, 12 Aug 2014 16:44:03 +
> 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 
> To: Chris Volpe ARA/SED , "lucas.pet...@engilitycorp.com"
> , "cmake@cmake.org" 
> Cc:
> Date: Tue, 12 Aug 2014 19:37:47 +
> 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

Re: [CMake] Possible bug in environment variable expansion?

[Chris Volpe ARA/SED]

Andrew-

You are correct that it was a Windows issue, not a CMake issue. See the post I 
made about two hours before yours.

The problem isn’t the alphabetic ordering, though. Is the “type” of environment 
variable. There are two types, “expandable string” and “string”. (There are 
other types for other general registry values, but env vars can only be of 
these two types.) It seems that if you create an env var in the normal Windows 
GUI, the first value you give it determines which type it is. If it contains a 
reference to another env var, it’s created as “expandable string”, otherwise 
it’s “string”. The type of the variable isn’t updated if you update the value, 
so the first value you gave to BOOST_LIBRARYDIR in your test below made it type 
“string”, even though you modified it to reference %BOOST_ROOT% later. You need 
to use RapidEE (http://www.rapidee.com/en/about ) to change 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] Possible bug in environment variable expansion?

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, 
mailto:cmake-requ...@cmake.org>> wrote:
Send CMake mailing list submissions to
cmake@cmake.org<mailto: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<mailto:cmake-requ...@cmake.org>

You can reach the person managing the list at
cmake-ow...@cmake.org<mailto: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" mailto:fmil...@sjm.com>>
To: CMake MailingList mailto:cmake@cmake.org>>
Cc:
Date: Tue, 12 Aug 2014 16:44:03 +
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 mailto:cvo...@ara.com>>
To: Chris Volpe ARA/SED mailto:cvo...@ara.com>>, 
"lucas.pet...@engilitycorp.com<mailto:lucas.pet...@engilitycorp.com>" 
m

Re: [CMake] Possible bug in environment variable expansion?

[David Cole via CMake]

There are no "types" for environment variables.

There are types for values stored in the registry.

See this article: http://support.microsoft.com/kb/256986 and note the 
descriptions of REG_SZ and REG_EXPAND_SZ.


The fact that you can do it in RapidEE does not mean it's a built-in 
feature of Windows environment variables. It means they have a nice 
feature built on top of Windows environment variables, ... but you 
can't count on that feature for use from *any* program that deals with 
environment variables. You can only count on it when you are setting an 
environment variable via RapidEE's user interface.



David C.

--

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

Re: [CMake] Possible bug in environment variable expansion?

[Chris Volpe ARA/SED]

David-

> There are no "types" for environment variables.

Not in other operating systems, perhaps, but I think it's perfectly reasonable 
to adopt the colloquial operating definition that, in Windows, the "type of an 
environment variable" is the type of the Registry value used to hold that 
environment variable.

> See this article: http://support.microsoft.com/kb/256986 and note the 
> descriptions of REG_SZ and REG_EXPAND_SZ.

I don't think I've said anything that indicates that I don't already understand 
what's contained there.

> The fact that you can do it in RapidEE does not mean it's a built-in feature 
> of Windows environment variables.

Given that the environment variables are stored in the registry, I'd say that 
*does* mean it's a built-in feature of Windows environment variables, insofar 
as it's a built-in feature of the implementation of environment variables on 
Windows.

> but you can't count on that feature for use from *any* program that deals 
> with environment variables. You can only count on it when you are setting an 
> environment variable via RapidEE's user interface.

Apparently, I can count on the setting of that type in RapidEE as having a 
profound impact on what value is reported by the "set" command in cmd.exe. I'm 
having a hard time figuring out what your point is. I'm merely trying to point 
out Windows behavior which, 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 Cole [mailto:dlrd...@aol.com] 
Sent: Friday, August 15, 2014 11:57 AM
To: Chris Volpe ARA/SED; andrew.amacl...@gmail.com; cmake@cmake.org; 
lucas.pet...@engilitycorp.com
Subject: Re: [CMake] Possible bug in environment variable expansion?

There are no "types" for environment variables.

There are types for values stored in the registry.

See this article: http://support.microsoft.com/kb/256986 and note the 
descriptions of REG_SZ and REG_EXPAND_SZ.

The fact that you can do it in RapidEE does not mean it's a built-in feature of 
Windows environment variables. It means they have a nice feature built on top 
of Windows environment variables, ... but you can't count on that feature for 
use from *any* program that deals with environment variables. You can only 
count on it when you are setting an environment variable via RapidEE's user 
interface.


David C.

-- 

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

Re: [CMake] Possible bug in environment variable expansion?

[David Cole via CMake]

OK, I partially take it back, you can set an environment variable that
references other environment variables even through the Windows UI...
But it's a little hard to grasp, because you see it when you're editing
the value, but then when you click OK, the view shows the resolved
value in the result. Combine that with the fact that I nearly always
avoid setting machine-wide env vars, and you can see why I might assert
the type-less-ness of env vars.

But even then, when you inspect the values with "set" or "echo" in a
cmd prompt, there's no evidence of the nested variable, because the
value you get back resolves the contained/nested reference.

The same is true of any other program that calls "getenv" and inspects
values in the environment. Windows resolves the references before it
gets to the program consuming it.

To set a "nested" value via CMake you should use CMake ENV syntax all
the way through, but it will be stored only as a plain old string type
when set via CMake. Plus... any value you set via CMake only takes
effect for the duration of that CMake run.

In other words, your initial attempt to do something like:

set(ENV{VAR} "%NESTED_VAR%")

should be written as:

set(ENV{VAR} "$ENV{NESTED_VAR}")

Although, the limited duration of the scope of such a construct makes
it useful only for the duration of running a CMake script, or of the
configure/generate process.

Sorry for the confusion. I could have been more clear in my email this
morning by saying "cross platform programs using environment variables
in a portable way will likely not have an implementation for dealing
with Windows nested environment variables properly..." -- which is
definitely the case for CMake and friends.


HTH,
David C.


-- 

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