OpenEuphoria

Re: Independent Euphoria Interpreter

• Posted by Juergen Luethje <j.lue at gm?.?e> Dec 14, 2007
• 575 views

Pete Lomax wrote:

> Matt Lewis wrote:
> >
> > Juergen Luethje wrote:
> > >
> > > Some comments about the updated page.
> > >
> > > On the page it currently reads:
> > > | Specifying a config file on the command line would preclude looking in
> > > | the other places.
> > >
> > > Yes, this will provide maximal flexibility.
> 
> I disagree. If you run an app and it cannot find say libX, then you should
> just
> be able to specify where libX is on the command line, rather than libX, and
> machine.e, and win32lib/wxEuphoria, etc. Of course look where the command line
> says first, but if you do not find it I can think of no reason to prohibit
> looking
> elsewhere.

When I specify a config file on the command line, then I should have a
special reason to do so. IMHO the command-line is not a proper place to
store default values. And when then say libX is not found, that probably
indicates that the specified config file does not contain the include
directories that I expected it to contain ... or the directories specified
in the config file do not contain the source code files that I expected
them to contain. Anyway, I think I'd prefer to get the information that
the desired stuff was not found, so that I can correct/update the config
file or the concerning include directory.

> > > Should more than one file be allowed?
> Perhaps. You might equally want a semicolon separator in the -i option.
> 
> > When we talk about 'relative paths' are you saying relative to the
> > interpreter?  Does that only make sense for the local conf file?  It seems
> > like you'd almost have to.  What do relative paths mean for the other files?
> 
> From a windows perspective, if you're running C:\euphoria\bin\exw.exe then
> obviusly it ought to look for includes in C:\euphoria\include\. I would
> therefore
> expect there to be a file C:\euphoria\bin\euinc.conf (ie same dir as exw.exe)
> which contains the relative path "..\include\"

Yes, that's what I was meaning.

> (and/or attempt that as a last resort if no config file can be found).

For being able to use Euphoria as a portable app, it is important that
the interpreter looks in it's own directory for a config file *not* as a
last resort, but with a _higher priority_ than looking e.g. in %APPDATA%
or %ALLUSERSPROFILE%.

> IMO relative paths should be relative
> to the location of the .conf file they are specified in,

Very interesting idea!! I'll have to think about it more in depth.
( This will not guarantee any sound result, though.  )

> and a -i relative path should be relative to the current directory.

Hmm ... I do not like the concept of "current directory".
My current directory probably changes every 10 minutes or so.
I prefer it when
     cd C:\mydir
     exw myapp.exw
and
     exw C:\mydir\myapp.exw
exactly behave the same way, so that it's not necessary to change the
current directory in order to achive a specific result.

And when using a file manager such as Total Commander (TC) instead of
the Windows Explorer, does then displaying a particular directory also
mean that this one now is the "current directory"? As far as TC is
concerned, the answer by it's author is "yes". But what about all the
other file managers out there?

> You may also want a special notation such as "%%..\include\" whereby the %%
> is replaced with the location of exu/exw.exe.
> 
> > > |   * command line switches
> > > |         * -c command line switch
> > > |         * -i command line switch (a specific directory)
> > >
> > One is a config file (using the -c switch), and another is passing a
> > directory right there on the command line.
> Personally I would reword that as:
>    * command line switches
>          * -c <config file>
>          * -i <directory of euinc.conf>
> 
> Lastly, can you add a note that if %APPDATA% and/or %ALLUSERSPROFILE% do not
> exist then the corresponding step is skipped (rather than crash/error out).

Yes, of course. For instance, if not config file is found, this would be
the same as if we now have "empty" EUDIR and EUINC environment variables.
That shouldn't cause a crash.

Regards,
   Juergen