Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

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... 
> <mailto:tac...@li...>> wrote:
>
>     Greetings,
>                     Ok! Message well received... simply using ACK_HOME
>     with no magic tricks then!!
>
>     Carl
>
>
>
>     -------- Original message --------
>     From: u-...@ae... <mailto:u-...@ae...>
>     Date: 2019/03/07 16:49 (GMT+08:00)
>     To: Carl Eric Codere <cec...@ya... <mailto:cec...@ya...>>
>     Cc: tac...@li...
>     <mailto: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...
>     <mailto:Tac...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tack-devel
>