From: groepaz (groepaz_at_gmx.net)
Date: 2001-12-10 16:54:02
Hello Ullrich,
Monday, December 10, 2001, 11:19:26 AM, you wrote:
UvB> Hi!
UvB> On Sun, Dec 09, 2001 at 05:01:03PM +0100, groepaz wrote:
>> oh btw UZ.... there's a little flaw in the assembler (maybe in the
>> compiler aswell) related to the "include" directive and relative
>> paths... looks like always uses the location of the directory where
>> ca65 has been run to complete relative pathes in any files (rather
>> than the location of the file were the include occurs) ... this kinda
>> makes it annoying to write general include files (which in turn,
>> include other files etc) except you use absolute pathes.
UvB> You may want to use the "-I directory" option to add an include search path.
UvB> Include files with relative paths are searched relative to any given include
UvB> directory and relative to the current directory (because "." is added to the
UvB> search path when the compiler/assembler starts).
UvB> I think both options (searching relative to the directory where the include
UvB> file resides vs. searching relative to the current directory) may be confusing
UvB> sometimes. And there is even a third option: Search relative to the directory
UvB> where the main source file is located.
UvB> Using -I should solve all these troubles.
err... sorry, no :o) using -I is not a "clean" solution.... for once
it would mean that each .inc file has to have a unique filename (which
is not an option for me since i have "config.inc" etc in various
directories) and nonetheless it makes it impossible to write code (and
makefiles etc) that is totally independent of absolute local paths.
from my understanding "-I" should be used to tell the assembler where
to find "common" includes (such as common libraries of your "OS") but
NOT where to find includefiles that are selfcontained within the code
you are trying to compile.
!
+-cc65
! +-bin this dir added to exe-search path
! +-lib this dir added to include path with "-I"
! +-include this dir added to include path with "-I"
!
+-c64
+-dev
! +-bin this dir added to exe-search path
! +-lib this dir added to include path with "-I"
! +-include this dir added to include path with "-I"
!
+-projects
+-work1 makefile for exe1,exe2 lives here
! +-exe1
! +-exe2
! +-common common code for exe1,ex2 lives here
! +-test
+-work2
(before you ask, i add "lib" directories to include path so i can
include them .s files for some quick'n'dirty testing - its ofcoz not
necessary usually)
ok, now let me explain.....
in /work1 ,/work2 etc are some different projects, that is code that
belongs together and is selfcontained except common system libraries
which live in cc65/lib, cc65/include, (libs that come with the
compiler) and c64/dev/lib, c64/dev/include (my own libs, just to keep
them seperated).
now lets say /common keeps a couple of .inc files which are beeing
used by both /exe1 and /exe2 .... to make things more obvious, also in
/common/test there is some code that uses those files.
in /common lives a file "global.inc" that looks like
.include "config.inc"
.include "more.inc"
.include "etc.inc"
... all included files live in the same directory as global.inc
soooooo to make a point, the behaviour i'd expect would be like:
a) regardless whats the current working dir when i type "make", the
stuff should still work => this renders "searching relative to ."
useless.
b) the same (unmodified) files in /common should work for all /exe1,
/exe2 and /test .... => this renders "searching relative to main
sourcefile" useless.
(a+b are pretty related to each other as you can see)
c) code should compile (assemble) without change regardless of its
location in the local filesystem => this forbids using "-I" option in
the makefile for adding all and every directory that keeps .inc files
(apart from this would be a really ugly solution for big projects - i
tend to split my stuff in lotta small files)
whatever, all and all these problems can be easily solved by
"searching relative to current file" aswell (right after searching
pathes given by -I option at best) - and thats actually the kind of
behaviour i'd expect from any decent compiler/assembler out there.
(except borland turbo-c which suffers from the same problem hehehehe ;D)
infact, i was pretty surprised that ca65 did NOT work like this when i
first stumbled about it....seems to be another "too easy to let it be
unfixed" issue to me ;=)
--
Best regards,
groepaz mailto:groepaz_at_gmx.net
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET