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