Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

Filesystem layouts are pretty standard, actually, so precompiled binaries
will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
on whether the binaries are supplied by the distribution or third-party.
(Or {share,libexec} for the BSDs.


On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:

> Greetings,
>                  Ok to keep as backup, it makes sense, on the other hand,
> for those systems where prebuilt binaries will be provided, this constant
> will not be very useful...
>
>
> Carl
>
> On 2019-03-07 21:28, David Given wrote:
>
> We do still need the hard-coded path as a fall back --- we can't require
> end users to set an environment variable just to run a normal binary. I
> think we're going to need to keep em_path.h to configure this.
>
> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
>
>> Greetings,
>>                 Ok! Message well received... simply using ACK_HOME with
>> no magic tricks then!!
>>
>> Carl
>>
>>
>>
>> -------- Original message --------
>> From: u-...@ae...
>> Date: 2019/03/07 16:49 (GMT+08:00)
>> To: Carl Eric Codere <cec...@ya...>
>> Cc: tac...@li...
>> Subject: Re: [Tack-devel] ACK_HOME and em_path
>>
>> Hello Carl Erik,
>>
>> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel
>> wrote:
>> > Greetings,
>> >               Is it ok if eventually em_path.h is completely removed
>> and is replaced by something that is checked at runtime instead of compile
>> time? I do feel that doing this at compile time gives a bit of a limit on
>> moving the install directory.
>> >
>> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I
>> already implemented it in the ANSI C porting.
>> >
>> > Now for EM_DIR, I propose the following:
>> > * ACK_HOME environment variable would need to be set for it be used and
>> should point to ACK install directory.
>>
>> Consequently using a dedicated environment variable is good.
>>
>> > Now the additional question, let us assume ACK_HOME is not set, do we
>> simply fail, or do we try to check additional things, like the following:
>> > ** If argv[0] contains a path, from there find and set ACK_HOME by
>> deducing the installation path?
>> > ** If argv[0] contains no path, search the PATH environment variable
>> for the executable and from there deduce the installation path?
>>
>> IMO (basically any) implicit heuristic search is harmful.
>>
>> It makes un-/underconfigured installs deceptively look "right" and
>> leads to headaches when things assumed to "magically just work" subtly
>> work not exactly as one expected.
>>
>> Neither argv[0] nor PATH are reliable pointers to the actually needed
>> resources, nor the path to the running executable, even when it could be
>> reliably found out on some platform.
>>
>> Nor should they be assumed/constrained to be set up for such use,
>> because they also are under other unrelated constraints and carry or may
>> carry other important functions as well.
>>
>> In other words, compiler development and system administration are
>> different domains, it is highly unreliable to make assumptions across
>> their borders.
>>
>> As a matter of fact, I have to go out of my way to prevent possible harm
>> from gcc's resource guesses from its argv[0].
>>
>> Please do not make ack act in such fashion.
>>
>> Rune
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>
>