1. Includes and subdirectories
- Posted by Scott Murray <FaIkon1313 at AOL.COM>
Apr 24, 1999
-
Last edited Apr 25, 1999
Is there a workaround or fix for the inability to include from
subdirectories yet? I feel sure somebody must've found a way to do it, but I
must've missed it.
What I mean, is that I've got my .ex program source in a directory, and
all the includes in a subdirectory, which works fine except that most of the
includes include each other and they're not resolved properly by the
interpretor.
--c:\dev\euphoria\projects\test.ex
include gui\all.e --works
--c:\dev\euphoria\projects\gui\all.e
include dialog.e --crashes with "can't open
--c:\dev\euphoria\include\dialog.e or
--c:\dev\euphoria\projects\dialog.e"
include gui\dialog.e --seems to indicate that it should look in
--c:\dev\euphoria\projects\gui\gui\, but
--it doesn't, it looks in the right place,
however
--dialog.e includes another one of the
files, so it
--crashes anyway. :/
Of course, I can go through all 30 includes and resolve the pathnames
manually, but that seems to obliviate the purpose of using relative
pathnames... OTOH, I could just dump all 352 .e files on my hard drive into
the EUDIR\Include directory, but besides the conflicts that'd just be messy.
frustrated that I must've overlooked something obvious...
2. Re: Includes and subdirectories
Scott Murray writes:
> What I mean, is that I've got my .ex program source in a
> directory, and all the includes in a subdirectory, which works
> fine except that most of the includes include each other and
> they're not resolved properly by the interpretor.
Someone pointed this out before. Euphoria looks in the
directory containing the main .ex (.exw) file, then it
looks in euphoria\include. You can also provide the full path.
Some applications would benefit from a more sophisticated
scheme. I'll look into improving this, perhaps as part of a
general improvement of the "namespace" situation.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Includes and subdirectories
|
|Euphoria looks in the
|directory containing the main .ex (.exw) file, then it
|looks in euphoria\include. You can also provide the full path.
|Some applications would benefit from a more sophisticated
|scheme. I'll look into improving this, perhaps as part of a
|general improvement of the "namespace" situation.
|
|Regards,
| Rob Craig
Another language that I use, Progress (http://www.progress.com) , uses a
PROPATH environment symbol to list the directories that it will search. It
provides a few built-in functions to support it as well.
SEARCH(<file>) Will look for the named file in the PROPATH directories
(unless a full pathname was given).
PROPATH() Returns the PROPATH evnironment string.
PROPATH = "..." Sets the PROPATH for the remainder of the session.
--------
cheers,
Derek Parnell
dparnell @ vic.bigpond.net.au
Melbourne, Australia
4. Re: Includes and subdirectories
From: Rob Craig
>Someone pointed this out before. Euphoria looks in the
>directory containing the main .ex (.exw) file, then it
>looks in euphoria\include. You can also provide the full path.
>Some applications would benefit from a more sophisticated
>scheme. I'll look into improving this, perhaps as part of a
>general improvement of the "namespace" situation.
That will be good. 
In the meantime I've stumbled across a
related quirk that some experienced or creative programmers
might be able to find a use for: One-time run-time-modifiable
includes. (via dot-directories)
Don't know if this has been done before or not, but it popped
into my head while I was trying to sleep and I just had to try it
out.
-----[ hey.e ]-------
global procedure hey_1()
puts( 1, "Hey!\n" )
end procedure
------[ hey.ex ]--------
include hey.e
object fn
fn = open( "hey.e", "w" ) --must be in write mode to avoid 'attempt to
redefine'
--overwrite the old routine with a new one
puts( fn, "\n" &
"global procedure hey_2()\n" &
" puts( 1, \"Hey hey!\\n\" )\n" &
"end procedure\n" )
close( fn )
include ./hey.e --Include it again. If a 'different' path is used,
--EU won't realize it's already been included.
--Dot-directories count as a different path.
--( OTOH, even though it's a different file, if
-- the path's the same, EU won't re-include
-- it. )
hey_1() --still callable, but no longer in the source.
hey_2()
------[end code]-------------------------------------------------------
It doesn't look very useful, but if the include file consisted
only of assignments and statements rather than declarations
then you could do the customization once each run-time
instead of only once...
But then it would just be a tricky datafile that could call
code but which could only be loaded once per run, eh? Like
an active INI file...
Although if you combined it with the one-time conditional
include method that was posted before...
Dunno, just thinking sideways.
