Re: [Tack-devel] ACK_HOME and em_path

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

Greetings,
                 Thanks for clearing this point of, i did not grow up in 
UNIX environments... so i was not sure on this one.

As i said in a previous email, i have some crazy ideas, but the other 
platforms for ACK that I immediately see on top of the linux, BSD, MacOS 
are of course native Windows, MS-DOS and maybe AmigaOS.. And I see from 
the code I have looked up to now, it would be possible ... as long as 
addressable code space is more than 64K...

Because of technical limitations on some of those platforms, i would not 
actually build ACK on those platforms, but more cross compile to have 
ACK available for those platforms... I do feel it is possible...  But of 
course its a very long way off before this can be achieved .... :)

Carl



On 2019-03-08 00:24, David Given wrote:
> /opt vs /usr/local has been a long-standing holy war --- there's 
> really very little in it. There both intended for add-on packages not 
> supplied with the system. I grew up with /usr/local, so that's the one 
> I picked. Anyone building distributable binaries will customise the 
> setting anyway.
>
> When you say 'other platforms', which ones do you mean? AFAIK OSX, 
> Cygwin and Haiku all use /usr/local, or close-enough.
>
>
> On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya... 
> <mailto:cec...@ya...>> wrote:
>
>
>     Greetings,
>     ����������������� Actually I am
>     more confused after your answer! If I build ACK for the MS-DOS
>     target, what would be the value of EM_DIR in this case? C:/ack ?
>     On Windows, it would really depend, there is a standard location,
>     but it could be anywhere else. In all cases, i will keep as
>     proposed and my comment does not change anything.
>
>     Regarding the install paths, i see that the new installation paths
>     are different than the ones provided in the original ACK
>     installation guide... and also different than the recommendation
>     from the linux foundation.
>
>     The linux foundation recommends /opt/<package> with the different
>     standard subdirectories under it... but maybe this is for binary
>     installs only, and it does not apply to other UNIX flavors?
>     The issue with the new directory structure which I have seen is
>     hardly portable to other platforms except UNIX like systems... i
>     see lib/ack and share/ack.
>
>     Sorry for all this trouble and questions...
>     Carl
>
>
>
>
>
>     On 2019-03-07 23:02, David Given wrote:
>>     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...
>>     <mailto: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...
>>>         <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
>>>