Page 2 of 2

Re: Where does the compiler search for libraries?

Posted: Fri Aug 01, 2014 9:16 am
by SHughes_Fusion
That is useful to know, but why do I also have an Includes folder in My Documents/Swordfish?

That might actually explain a problem I was having a while back as I tried editing a processor file to fix a problem but without success. The one I altered was in My Documents which presumably means it wasn't actually used?

Re: Where does the compiler search for libraries?

Posted: Fri Aug 01, 2014 9:47 am
by David Barker
I'm not aware of the installer or application creating an "include" folder in my documents

C:\Users\<name>\Documents\Swordfish

Maybe this is something you have done in the past? Try deleting this folder and run the install again. If it creates a folder, let me know and I will check it out.

Re: Where does the compiler search for libraries?

Posted: Fri Aug 01, 2014 10:19 am
by SHughes_Fusion
You must be right, David, this must be something from the past. I did as you asked and it didn't come back.

All I can imagine is that I will have copied the contents of my Swordfish folder from previous installs so it must have come from there. Was the Includes folder ever in My Documents? For example in the SE compiler?

Re: Where does the compiler search for libraries?

Posted: Fri Aug 01, 2014 2:45 pm
by David Barker
> Was the Includes folder ever in My Documents? For example in the SE compiler?

No, the only includes folder should be as previously described for both the SE and full version of the compiler.

Re: Where does the compiler search for libraries?

Posted: Tue Nov 25, 2014 11:35 am
by RangerBob
Hi David,

I know I'm late to the party here but is there any chance I could beg you to put in a switch for this updated library search behaviour, so I can force it back to the old way?

Let me explain my problem: I have just come back to some new projects, and revising some old ones since this update took place after a break.

Previously if I needed a custom version of a standard library for a project, I simply copied it out of userlibrary (or systemlibrary) (eg. USBCDC.bas) put it into the project directory, made my changes leaving the name intact and voila, when compiled swordfish picked the project directory version as needed. If I decided later I didn't need it, I could just delete the project directory version, and it went back to the userlibrary version. Anything needing standard was unaffected, and I believe this was the preferred way of working.

However now I've started working on another project since the update; and instead of picking up the Vanilla version of the USBCDC.bas in userlibrary as before, the compiler is picking up the first USBCDC.bas version it stumbles across in the first project directory it spots. Yes I can go through and modify every project to have a unique USBCDC.bas name, but at this point I have >50 projects that may or may not need modifying, and trying to iron each one out is a major PITA and a major risk of breaking something important.

Best Regards,

Nathan (Rangerbob)

Re: Where does the compiler search for libraries?

Posted: Tue Nov 25, 2014 11:43 am
by David Barker
> the compiler is picking up the first USBCDC.bas version it stumbles across in the first project directory it spots

Are you saying it is picking up USBCDC from any available project? It should only search subfolders contained within the root project. For example, if compiling for "progMain.bas"

myProgram\progMain.bas <- compiling this
myProgram\modules\usbcdc.bas <- will use this

anotherProgram\progMain.bas
anotherProgram\modules\usbcdc.bas <- should NOT use this

Re: Where does the compiler search for libraries?

Posted: Tue Nov 25, 2014 12:41 pm
by RangerBob
I have a number of general projects stuffed into the root project folder, then I have a number of projects separated into their own folders. Ie.

testproject1.bas
testproject2.bas
testproject3.bas
> project1dir
> > project1.bas
> > USBCDC.bas
> project2dir
> > project2.bas
> > USBCDC.bas
> Userlibrary
> > USBCDC.bas

(Hope that makes sense)

If I compile testproject1.bas and it #includes "USBCDC.bas" it picks it from the project1dir directory, rather than the UserLibrary as previous. If I compile project2.bas, it correctly picks out its own USBCDC.bas as it should.

I guess its just more down to my poor organisational skills, and I'll just have to separate everything into its own sub-directory. It was just a real panic when I couldn't figure out why it was grabbing files from weird places.

Regards,

Nathan

Re: Where does the compiler search for libraries?

Posted: Tue Nov 25, 2014 3:37 pm
by David Barker
testproject1.bas
testproject2.bas
testproject3.bas
> project1dir
> project1.bas
> USBCDC.bas
> project2dir
> project2.bas
> USBCDC.bas
> Userlibrary
> USBCDC.bas
Just move your programs into a folder, it shouldn't break anything. For example,

|-mainproject1\testproject2.bas
|-mainproject2\testproject3.bas
|-project1dir\
...

Re: Where does the compiler search for libraries?

Posted: Wed Jan 28, 2015 3:51 pm
by SHughes_Fusion
Sorry for re-opening an old topic but I'm hitting this problem again.

Can I ask again, can we either turn this search option off or if not can the search order at least be made a bit more restrained?

I've created a test program in my 'Programs' root directory. I've been debugging for ages to see why it didn't work and have just spotted that it has grabbed an old copy of a library. Swordfish is drilling down 4 folder layers to find this copy....

Would it not make more sense for the search order to be something like:
Current directory (and maybe one level down, but I'd like to see this in a named folder only)
User Library
Default Libraries
If all else fails find anything anywhere.

That way you can put custom libraries in the same folder (or in a folder something like 'CustomLibrary') but for anything else it will go to the 'standard' libraries before it searches elsewhere. At the moment it seems to look there last which does not seem a sensible approach.

I know there are work-arounds (copying to a subfolder for example) but this is the sort of problem you only hit occasionally and so forget about this problem and have to keep re-learning.