Re: [Tack-devel] ACK_HOME and em_path

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

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
>