OpenEuphoria

Re: Include File Relative Paths

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 08, 2007
• 535 views

c.k.lester wrote:
> 
> Pete Lomax wrote:
> > I really think you want to manage this properly/manually, eg:
> > 
> > }}}
<eucode>
> > global ciDir   -- current include directory
> >        ciDir=""
> 
> I don't think a variable in the global namespace is proper in this case
> (or ever, really) when all I'm trying to do is open a file relative to
> the calling file.

You seem to miss the point that you cannot and must not change open().
You will break thousands of existing programs (including Edita!).

However I suppose you could do this:
1) extend the enhancements to path_open so that the new currdir variable is
always left with whatever path actually succeeded.
2) add a new builtin open_relative(name,mode) which is just like open except
that it emits tmp=currdir&name open(tmp,mode).

<snip>
> Why would one want to do that? Portability! Maintainability!
I know! I have had relative includes working myself nearly a year now. Very nice
they are too. (Just a shame the rest of my language isn't finished.)


> When somebody takes my c:\htdocs\plugins\superPlugin code directory and puts
> it into their program's directory (which might be z:\net\htdocs\release\,
> they can simply include the include file and it will all work... no include
> path modifications required. That's how it should be.

Wait a minute here. So you are saying that they can dump it in \release, or
\release\superPlugin, or \release\junk and it has to work in all cases??
Otherwise why not just use a "superPlugin" constant?? Or are you saying you have
a component and you don't want to tell it what it is part of? Why not?

Confused now,
Pete