Re: include path problem [WAS: STANDARD EUPHORIA LIBRARYS]
- Posted by Jason Gade <jaygade at y?hoo.com> Aug 05, 2007
- 548 views
Bob Elia wrote: > > C.K. Lester wrote: > >Bob Elia wrote: > >> > >> I am currently using version 3.0.2 because the include path changes break > >> several of my programs; apparently, I'm the only person on earth with this > >> problem since it's never been mentioned. > > > >Just FMI, could you give an example where that change broke some code? I > >can't > >imagine a case where looking one more spot for include files would break > >code. > > Hi CK, > > Sorry for the delay. The problems I am having are namespace conflict errors, > so it's only in that sense that they break my code. The problem is that > I'm using a rather unorthodox, though legal under the old rules, EUINC. > I am aware that this is NOT recommended practice. > > I had been in the habit of installing each new version of euphoria in a > different directory and then prepending it's include directory to EUINC. > So, the latest %EUDIR%\INCLUDE would always be at the beginning of EUINC > so a program would always find the current standard includes first. > New libraries would be installed in the current installation's ...\INCLUDE. > If I wanted to compare versions I could run a batch file which would change > the current installation by changing EUDIR and EUINC. > > What happens under the new rules is that a library residing in an old > ...\INCLUDE path which includes a standard file gets it from that old > directory. Then, later on, another file includes the same filename but > gets it from the current installation's ...\INCLUDE thus causing a > namespace error. > > Some time ago I created a single directory, separate from any installation, > called \EULIBS\ for new libraries. I've managed to fix the errors I was > getting > as they occur by moving old libraries out of the old .../INCLUDE/ directories > into EULIBS. > > This looks simple at first glance but there are (or perhaps were) user > contributions which contained mods of files that were not renamed. That's an interesting method. I don't usually mix old libs and new libs; however I usually make a new folder under my EUDIR and name it lib and that's where I dump contributed libraries. Except for bigger libraries such as wxEuphoria (although that has changed with 0.10.0) and win32lib. They usually get their own directories. > By the way, has anyone written anything which makes use of the new rules? Good question. I remember being advocate for it but I haven't used it yet. > Now, another problem. Try this: > > }}} <eucode> > -- O:\TESTSAFE\TESTSAFE.EX > > include machine.e -- copied from %EUDIR%\INCLUDE\safe.e as MACHINE.E > -- into this program's directory as per REFMAN.DOC > > include database.e -- includes machine.e > > atom a > > a = allocate(1024) > > ? a > > while get_key() = -1 do end while > -- end of file > </eucode> {{{ > > This results in: > > L:\progra~1\EUPHORIA\INCLUDE\database.e:127 > A namespace qualifier is needed to resolve allocate. > allocate is defined as a global symbol in: > .\machine.e > L:\progra~1\EUPHORIA\INCLUDE\machine.e > > mem0 = allocate(4) > ^ > > Can anyone reproduce this error? > > This used to work because of the "include once" behavior. What now? > If this is not due to my error, then perhaps the docs will have to > be changed to recommending renaming safe.e to machine.e in %EUDIR%\INCLUDE\. > This could be done with a batch file. > > Bob Yeah, this is confirmed. I haven't started on it yet, but I was going to experiment with an "import" keyword which worked exactly like "include" only global symbols included other than directly would not propagate to the main program. I haven't started on it yet, I've just been thinking. I'm also working with wxEuphoria stuff (albeit slowly) so I can't promise anything in a timely manner, if at all. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.