Re: [Tack-devel] ACK_HOME and em_path

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

Yup, it's just the compiler driver. It needs to know where the descr files
are, which it then uses to set things like the include and library paths
and where to find all the other tools.

Requiring the end user to set an environment variable is possible, but
pretty antisocial; after installation the tools are expected to Just Work.
On platforms like DOS and Windows applications traditionally add their
variables to the environment. On Unix-y systems this requires a manual step
and should be avoided, hence the filesystem conventions. (I maintain a
couple of Debian packages and I don't think requiring the user to edit
their .profile after installation of a system package would get past
review.)

For precompiled binaries, whoever's doing the packaging is always going to
have to pick *something*, hopefully something appropriate for the platform
they're packaging. On a Linux system that'll nearly always be /usr. On a
BSD it'll probably be /usr/local (simply because of different conventions
there). If the binaries are intended to be installed by end users, then
they will obviously have to set the environment variable, because there's
no fixed location that'll work. The value shipped by default doesn't have
to be globally right, merely convenient for developers --- /usr/local is
the typical choice here because it works in most places.

So what we need is:

(a) a hardcoded location, which will be used in the normal situation;
(b) a way to override that if necessary.

Hence the existing behaviour with em_path.h and ACKDIR.


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

> 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...> 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...> 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
>>>>
>>>
>