[36127] trunk/base/doc/macports.conf.in

markd at macports.org markd at macports.org
Tue May 13 10:07:10 PDT 2008

>>>> Customizing binpath is intended for advanced users only.
>>>> +#binpath
>>> /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/
>>>> sbin:/usr/X11R6/bin
>>>> +
>>>>  # Directory containing the X11 installation.
>>>>  x11prefix            @x11prefix@
>>> Shouldn't we not hard-code the prefix and x11prefix, even if it is
>>> just a commented-out example line?
>> Maybe.  Would it be better to put psuedo paths in the comments such as
>> "/foo; /blah" or something?  I think the variable should be referenced
>> the file somewhere, and it seems awkward to list no path.  Also, I see
>> guide doesn't list the default binpath so that should be fixed.
>Just use @prefix_expended@ and @x11prefix@ which will get expanded on
>install. We already use them at other places in this file.

Are you saying that we should move where the binpath setting is set from
wherever it is now to macports.conf?  Also, what is @prefix_expended@
variable?  I'm not familiar with that.
>As a side note, maybe binpath should not be overwritten, but paths given
>in the config should be prepended to the default list. This would make
>it much easier to use this feature. But I am unsure if we really want
>users to make use of this as it allows third-party dependencies.

That's an interesting idea, but I'm not qualified to comment on the merits
of it.  I know binpath is little used, and we probably want it that way,
but I hate not to have it documented nonetheless in the usual places.  If
prepending the binpath makes it easier to use and developers like the
idea, given that we still want to discourage its use, perhaps we could
make the warnings against using it even scarier than "advanced users
only", and also issue similar stern warnings in the manpage/guide (the
same source in the new docs).

We're basically trying to solve the conundrum of documenting something we
don't want people to use.  But I'd like to document binpath on the idea
that we don't have features that aren't documented like all other features
so as not to cause unneccessary list traffic or user confusion, no matter
how infrequent.


More information about the macports-dev mailing list