Re: [Tack-devel] ACK_HOME and em_path

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

Greetings,
                    To make a compromise, knowing that this could lead 
to errors on certain systems... I propose the following after the 
fallback, or something similar:

    ...
#ifndef EM_DIR
     fatal();
#else
     return EM_DIR;
#endif


By the way, where this kind of common utility API that is specific to 
ACK be placed in? system? I am not sure if we have a location for this 
kind of common routines for ACK?

Ok for you all?
Carl


On 2019-03-07 22:52, Carl Eric Codere via Tack-devel 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... 
>> <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
>>
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel