OpenEuphoria

Re: Independent Euphoria Interpreter

• Posted by Matt Lewis <matthewwalkerlewis at gma?l.com> Dec 14, 2007
• 559 views

Juergen Luethje wrote:
> 
> Pete Lomax wrote:
> 
> > 
> > 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.

I can see a useful utility that would list out the include directories.
We could even add a special switch that would have the interpreter (or
translator) print out the directories in the order they will be searched.

But if it's not found, then you should get a dump of all of the directories,
and we can print them out in the correct order.

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

Yes, that's how I've got it coded, and I've fixed the wiki to reflect this.
 
> > 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.  )

It should probably be considered bad practice to use relative paths in
general, although I can see that it would be helpful in some cases.  I
can imagine a library developer possibly shipping these, as it would
make their directory structure more portable, and wouldn't require that
people change their system settings to try out the demos that come with
a library.
 
> > 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.

Since the -i is a command line only thing, the 'current directory' would
be wherever you ran the command.  If it's a problem, then don't use a
relative path in the command line.

Matt