Bug 678 - path problems with compiled files and the include directive
: path problems with compiled files and the include directive
Product: ECLiPSe
Classification: Unclassified
Component: Compiler
: 6.0
: PC Other
: P2 minor
Assigned To: Joachim Schimpf
  Show dependency treegraph
Reported: 2009-10-29 10:16 CET by Stephan Schiffel
Modified: 2014-04-16 01:01 CEST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Schiffel 2009-10-29 10:16:30 CET
Suppose we have the following files:

% somedir/p.pl

% somedir/include_p.pl
:- ensure_loaded("p").

% q.pl
:- include("somedir/include_p").

?- ["q.pl"].
works as expected.
?- lib(fcompile), fcompile("q").
?- ["q"].
throws an exception:

File does not exist :  in ensure_loaded("p")
*** compilation aborted in the file .../q.eco
Comment 1 Joachim Schimpf 2009-11-02 07:00:40 CET
Hmm, it's more tricky than I thought...  Certainly there should be no
inconsistency between compiling the .pl and loading the .eco!

However, in ECLiPSe 6.0, include/1 is supposed to have true include-semantics
(while in 5.X it was merely an alias for compile/1), which means that the
ensure_loaded(p) directive in somedir/include_p.pl should behave as if it
occurred in q.pl (which isn't what you expected).  When you fcompile q.pl,
you produce q.eco, which contains q.pl and include_p.pl (but not p.pl),
which means the original include-structure is lost.

The cleaner fix seems to me to have pure include-semantics, i.e. in an
included file you would have to assume to be in the includer's directory,
not the includee's.
PRO: SWI Prolog and YAP behave that way.

The fix it the other way (i.e. to make your existing code work), would mean
a less straightforward semantics for include/1, and some ugly trickery in the
.eco files to keep track of the original source code nesting.
PRO: SICStus and C behave like that when compiling (but they don't have the
problem that precompiled files can still contain directives!)