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