[CMake] $ENV usage and documentation

[Brandon Van Every]

On Jan 28, 2008 12:16 AM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2008-01-27 22:28-0500 Brandon Van Every wrote:
>
> > On Jan 27, 2008 8:34 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> 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