Thread: Re: [Tack-devel] ACK_HOME and em_path
Moved to https://github.com/davidgiven/ack
Brought to you by:
dtrg
Menu
▾
▴
tack-devel
|
From: Carl E. C. <cec...@ya...> - 2019-03-07 11:16:48
|
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 |
|
From: David G. <dg...@co...> - 2019-03-07 13:28:50
|
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 > |
|
From: <u-...@ae...> - 2019-03-07 15:16:10
|
On Thu, Mar 07, 2019 at 02:28:30PM +0100, 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!! Thanks Carl! OTOH I have to agree with David, hardcoding a path where an application looks for its resources is a traditional practice, a necessary fallback when a dedicated variable is not available. This is of course different from silently falling back on the hardcoded paths if a resource is not found via a _set_ variable. The latter would make it uncertain whether the intention to use a specific instance succeded or not. Regards, Rune |
|
From: Carl E. C. <cec...@ya...> - 2019-03-07 14:52:18
|
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
>
|
|
From: Carl E. C. <cec...@ya...> - 2019-03-07 15:04:00
|
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
|
|
From: David G. <dg...@co...> - 2019-03-07 15:03:18
|
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
>>
>
>
|
|
From: <u-...@ae...> - 2019-03-07 16:42:30
|
On Thu, Mar 07, 2019 at 04:02:58PM +0100, 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.
1. Isn't it just the compiler driver program which needs a specific setup?
It seems even respect environment vars like ACKDIR (looking at ack-5.5).
2. It is totally straightforward to keep all the stuff in a single
file tree and let people put the tree where they like.
Who is thought to be the consumer of precompiled binaries?
Setting an environment variable is not a big challenge for
an aspiring C developer, or is it?
This would drop the requirement for the recipient to be a superuser
(superuser can as well set up an environment variable, even for
all the users, or put a two-line bourne shell wrapper into
the PATH in use on the machine).
What needs fixing?
Rune
|
|
From: Carl E. C. <cec...@ya...> - 2019-03-07 16:49:06
|
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
>>
>
|
|
From: David G. <dg...@co...> - 2019-03-07 16:24:59
|
/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
>>>
>>
|
|
From: <u-...@ae...> - 2019-03-07 17:09:18
|
On Thu, Mar 07, 2019 at 05:24:37PM +0100, 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. OT for the list and this thread, but all those "holy wars" about "where stuff should be placed on every machine" were/are a result of a misconception. It is the hardcoded paths which make the exact placement "critical". As soon as one distingushes between 1. "having the stuff" (any path is good enough) 2. "running the stuff" (what we need is a reference in the PATH or menus or alike, I call this "inlaying") 3. "letting the program know where to find what it needs" (which is to give it environment variables or alike, instead of hardwiring this into the binaries) then it becomes apparent that the "administrative syncronization of paths everywhere" is an artificial (and of course not solvable :) problem, created by the intention to hardwire the references instead of letting them be specified as-needed. Rune |
|
From: Carl E. C. <cec...@ya...> - 2019-03-07 16:42:25
|
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
>>>
|
|
From: David G. <dg...@co...> - 2019-03-07 19:41:31
|
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
>>>>
>>>
>
|
|
From: Carl E. C. <cec...@ya...> - 2019-03-08 18:05:41
|
Greetings, Ok, I would rather call it ACK_HOME personally if you don't mind? As agreed we check the environment variable first then, we get the hard coded value if the variable is not available.
On the other hand, I think we need to support 2 types of directory structures, at least as i see it, because the current one is /usr/local is clean for UNIX systems, but it is not if you use /opt/ or for all other systems... I would keep the one in the install documentation.
The easiest way i see is to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think?
Carl
On Friday, March 8, 2019, 3:41:41 AM GMT+8, David Given <dg...@co...> wrote:
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
_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel
|
|
From: David G. <dg...@co...> - 2019-03-08 19:11:55
|
Do we need to support both? I mean, the only downside is that if you're
installing into /opt, your hierarchy ends up looking like
/opt/ack/share/ack/stuff.
Changing this would require a fair bit of replumbing as relative paths are
everywhere. Take a look at lib/descr/fe, for example. I've just tried
changing things in the driver frontend and it's *not* easy code to work
with.
On Fri, 8 Mar 2019 at 18:45 Carl Eric Codere <cec...@ya...> wrote:
> Greetings,
> Ok, I would rather call it ACK_HOME personally if you don't
> mind? As agreed we check the environment variable first then, we get the
> hard coded value if the variable is not available.
>
> On the other hand, I think we need to support 2 types of directory
> structures, at least as i see it, because the current one is /usr/local is
> clean for UNIX systems, but it is not if you use /opt/ or for all other
> systems... I would keep the one in the install documentation.
>
> The easiest way i see is to have em_path.h to contain all important
> directory defines directly relative to the root directory (either the
> environment variable or hard coded path) this generated at build time, so
> we can support both, and it has practically no impact on existing codes?
> What do you think?
>
> Carl
>
>
>
> On Friday, March 8, 2019, 3:41:41 AM GMT+8, David Given <dg...@co...>
> wrote:
>
>
> 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...>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
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>
|
|
From: <u-...@ae...> - 2019-03-08 19:09:56
|
On Fri, Mar 08, 2019 at 05:45:09PM +0000, Carl Eric Codere via Tack-devel wrote: > Greetings, Ok, I would rather call it ACK_HOME personally if you don't mind? As agreed we check the environment variable first then, we get the hard coded value if the variable is not available. May be rather not? Why invent a new name when there is an established one (ACKDIR?)? > On the other hand, I think we need to support 2 types of directory structures, at least as i see it, because the current one is /usr/local is clean for UNIX systems, but it is not if you use /opt/ or for all other systems... I would keep the one in the install documentation. Again, I think it is misdirected to make an effort directed at numerous (lot more than two) and generally incompatible with each other styles of system administration. It is not a problem at all to handle as an integrator, but becomes unnecessary bikeshedding, assumptions and constraints for the (Ack) developers. The documentation can (and IMHO strongly should) always refer to "$ACKDIR". A distribution-specific documentation can always do a substitution, especially if it is left as an explicit macro in the doc sources. The build system can do such a substitution, if it does not already (?) Having said that, explicitly referring to a variable is safest. Good if it is easy to find out in the docs "in this installation (which you read about) '$ACKDIR' is /...... and the compiler driver knows this, but you can always set $ACKDIR in your shell explicitly if you mean to use a separate copy/build/instance of Ack" If, say, an OS distribution wishes to split a single tree into many (which can be reasonable or not, but this by its nature is a problem outside our knowledge horizon), this is easy to do with symbolic links. Some platforms do not have symlinks-alikes, but hey, the corresponding ditributors _if_ they need separated trees can argue for what they need and why. _Then_ we can take up this discussion again. Some platforms do not have hierarchical file naming, shall we cope with this also? May be! But not before the need is apparent. > The easiest way i see is to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think? It sounds good, to define all paths so that they are derived at run time, but isn't this already the case? (not looking at the source right now) Rune |
|
From: <u-...@ae...> - 2019-03-08 20:41:44
|
On Fri, Mar 08, 2019 at 08:09:00PM +0100, u-...@ae... wrote: > > The easiest way i see is to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think? > > It sounds good, to define all paths so that they are derived at run time, > but isn't this already the case? (not looking at the source right now) I now checked with the (5.5) code and it looks exactly like what you describe: there is a default path defined at build time (possible to be overriden at run time) and one relative path. Which other directory defines you suggest to introduce there and why? I can only guess that this was for the various system administration tastes' sake (?) If correct, it would mean complicating the compiler for no reason. Please keep the structure straightforward, consistently documented, with as small connection to the system administration as possible. *** The fewer assumptions, the less headache for all parties. *** I appreciate your and David's efforts. That's why I care when precious time is spent on dicussing how to best support something which is marginally relevant, impossible to solve in general and at the same time an easy task for independent external means in every particular case. If not otherwise, it is far easier to map a single-file-tree software to a particular storage structure than to adapt from a _differing_ non-trivial file structure. Rune |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X