Re: [CMake] $ENV usage and documentation
On Jan 28, 2008 9:31 PM, Bill Hoffman [EMAIL PROTECTED] wrote: So, a small focused patch for documentation will be addressed much quicker than a large complicated patch. I will also say, documents have been getting fixed lately without patches, if the new text is trivial. Generally I just give the 1..2 sentences necessary, and someone else goes through the bother of getting it into the docs. I think that's as it should be, since for such small changes, constructing and applying patches is useless overhead for all parties. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On Jan 28, 2008 12:16 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2008-01-27 22:28-0500 Brandon Van Every wrote:
On Jan 27, 2008 8:34 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as $ENV{PATH} in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE
command).
However, when I tried, e.g.,
SET(pc_path $ENV{PKG_CONFIG_PATH})
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
Yes, that is exactly what I have done, but the question remains is this some
side effect that might be removed later or is the code meant to work that
way, i.e., is it a supported use?
As far as I know or can remember. You could check the mailing list
archives and the CMake sources for verification. Quick grep of ENV in
.cmake files should reveal exactly what's used in practice.
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
Well, it does sound like you have been successful with that approach so I
may adopt it, but generally I am quite hesitant to go through formal bug
reporting for stuff that can be fixed much faster than the time spent on bug
triage. IOW, I hope CMake developers read this list and when they see small
issues reported they fix it immediately rather than fooling around with bug
reports, assigning somebody to deal with it, etc.
But the more you ask them to do, like ask them to perform the
wordsmithing themselves, the less easy it is to drop what they're
doing and immediately fix the problem. Hence the stickiness of the
bug tracker. Also, isn't it unreasonable to expect them to drop what
they're doing to handle your priorities immediately? The bug tracker
has severity and priority settings; this is at best a severity=minor,
priority=normal issue. I'm sure you can appreciate that people have
lots of other things to do. Like I said, these documentation issues
are actually getting fixed lately when I file them (thanks especially
to Alex), so please respect Kitware's process and work with them.
Finally, there is no
point in me suggesting new documentation wording when questions like the
above are still outstanding.
I would simply assume that all the permutations of $ENV{x} ENV{x} ENV
x that you've seen are supported in their various contexts. Do the
wordsmithing to say, This is what's going on, in the appropriate
contexts. You're talking about ~3 permutations; if 1 of 'em turns out
to be unsupported, so what? It's not that much work on your part or
much text lost. The person who works on the doc changes will take
that into account, and possibly open a new bug to change actual code.
I don't see why you're so against bug triage except for response time.
I've said that response time is acceptable lately, and otherwise,
having a conversation in the bug tracker is like having a conversation
on the mailing list. Only it's sticky, more usable, and isn't
forgotten as easily.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On Jan 27, 2008 8:34 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as $ENV{PATH} in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE command).
However, when I tried, e.g.,
SET(pc_path $ENV{PKG_CONFIG_PATH})
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
The current documentation has a number of different references to ENV.
It refers to
$ENV{PATH}
one place (in a narrow context as noted above),
ENV var
several places, but in extremely specific contexts (which I presume could be
replaced by $ENV{var})
and
ENV{PATH}
in one place (an example showing how to use SET to write
the PATH environment variable).
Please document $ENV for reading and ENV for writing arbitrary environment
variables in at least the CVS version. A logical place for this general
documentation might be the SET command since as noted above that already
gives an example for writing the PATH environment variable.
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
One gotcha about set(ENV{var} blah) is that it only sets the CMake
configuration environment. It doesn't exist in the build environment,
as CMake is gone and we're not running under CMake's choice of shell
anymore. This gotcha should also be noted in the set() docs.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On 2008-01-27 22:28-0500 Brandon Van Every wrote:
On Jan 27, 2008 8:34 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as $ENV{PATH} in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE command).
However, when I tried, e.g.,
SET(pc_path $ENV{PKG_CONFIG_PATH})
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
Yes, that is exactly what I have done, but the question remains is this some
side effect that might be removed later or is the code meant to work that
way, i.e., is it a supported use?
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
Well, it does sound like you have been successful with that approach so I
may adopt it, but generally I am quite hesitant to go through formal bug
reporting for stuff that can be fixed much faster than the time spent on bug
triage. IOW, I hope CMake developers read this list and when they see small
issues reported they fix it immediately rather than fooling around with bug
reports, assigning somebody to deal with it, etc. Finally, there is no
point in me suggesting new documentation wording when questions like the
above are still outstanding.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
