DECLARE LIBRARY adding extra slashes to paths

[SMcNeill]

  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

They're needed internally (first backslash is an escape char) - you'll notice the extra ",14" indicating the length of the string. That's internal compiler intermediate representation, no need to worry about it.

[SMcNeill]

Except it's not finding the library which is right where it should be. 

If mem.h is moved into the same directory as the EXE, it'll find it with a path of "./mem", but it won't find it if we just DECLARE LIBRARY "mem".

Something isn't pathing as it should be properly.

[SMcNeill]

To add to the oddity, this works:

Code: QB64: [Select]

1.     $ExeIcon:'.\chessdat\chess.ico'
2.     Const slash = "\"
3.     Declare Library ".\chess\chessdat\mem" ' S McNeill CPU load tracking, Linux uses sensors
4.         Function GetCPULoad#
5.     End Declare

Notice the $EXEIcon has no problem finding the resource based off from where the .BAS file is located.  (It's in the /chess folder.)

The call to DECLARE LIBRARY, however, needs a path to be in relation to QB64.EXE, rather than where the chess.BAS is located.

It doesn't appear that DECLARE LIBRARY is looking for files in relation to the source code's folder, even if Export EXE to Source Folder is selected in the options.

To sum up the odd behavior I'm seeing here:

".\mem" *will* look in the folder with the BAS file and find our header file.
"mem" doesn't, though it seems like it should default to the same directory as the BAS file.
".\chessdat\mem" doesn't find the file, even though there's a copy of it inside the "chessdat" folder.  For whatever reason, it can't find the relative folder and the file inside it.

[FellippeHeitor]

Path resolution for declare blocks is a known issue, open at the repository as we speak. If you do any work on it before we do, let us know.

[FellippeHeitor]

https://github.com/QB64Team/qb64/issues/7

[SMcNeill]

Path resolution for declare blocks is a known issue, open at the repository as we speak. If you do any work on it before we do, let us know.

My schedule more-or-less frees up starting around mid-January.  If no one's dug into it before then, I'll see what I can find with it.  I'd never had issues with the before, so wasn't aware it was an issue for us.

[George McGinn]

Couldn't you use a ../ like you can when you have an INCLUDE?

For example:

Code: QB64: [Select]

1. endPROG:
2. ' *** CLOSE Log File
3. '
4.  
5. ' *** Remove work files if they exist
6. '$INCLUDE: '../include/deleteWorkFiles.inc'    
7.     PRINT #flog%, ">>>>> Executing endPROG"
8.     PRINT #flog%, ""
9.     PRINT #flog%, "": PRINT #flog%, "*** " + ProgramName$ + " - Terminated Normally ***"
10.     CLOSE #flog%
11.     SYSTEM
12. END SUB

The code snippet is part of a SUB located in the /include directory, because it is used in 3 programs. the deleteWorkFiles.inc is used in many of my programs in the project directory.

I've never tried this with DECLARE LIBRARY statements before, but wouldn't it still resolve correctly?