Re: [Tack-devel] ACK_HOME and em_path

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

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
>