LADSoft / OCIDE

Orange C Compiler IDE
GNU General Public License v3.0
14 stars 1 forks source link

Include directories not taken into account? #62

Closed GitMensch closed 4 years ago

GitMensch commented 6 years ago

Using the setup given in https://github.com/LADSoft/OrangeC/issues/76 ocide shows:

;============ Building Project libcob ============
;============ Compiling call.c ============
Error( 34)    C:\dev\gnucobol-2.2\libcob\call.c(115):  Cannot open include file "libcob.h" in function lt_dlsym

Despite the issue that the include was not done in function lt_dlsym (resetting the function name for messages after the function definition is ended is missing) it seems to show that the include directories somehow don't apply here.

Additional include paths are set to ..;..\build_windows and libcob.h is available as C:\dev\gnucobol-2.2\libcob.h. Note: it doesn't matter if the include path setting is relative as in the setting above or absolute to C:\dev\gnucobol-2.2;C:\dev\gnucobol-2.2\build_windows.

side note: I'll be away for the next days and won't respond to any issues.

LADSoft commented 6 years ago

there was an issue with \ before the ending quote, which I've resolved, but beyond that there is a subtle problem. When using the IDE the paths the compiler will use are relative to the project file, because they have to be relative to something and there is no other stable point of reference. Because you didn't put the project file in with the sources, the include paths based on where the project file is should be: ....;..\

GitMensch commented 6 years ago

Hm, it still doesn't work when using the absolute path C:\dev\gnucobol-2.2;C:\dev\gnucobol-2.2\build_windows:

;============ Compiling call.c ============
Error( 34)    C:\dev\gnucobol-2.2\libcob\call.c(115):  Cannot open include file "libcob.h" in function lt_dlsym

Do I miss something or should this work?

LADSoft commented 6 years ago

i'm not sure, it seems to work here. Did you set the include paths on the project or on the file? Are you building in debug or in release?

GitMensch commented 6 years ago

Rechecked on another machine with latest occe.zip.

Using "C:\dev\gnucobol;C:\dev\gnucobol\build_orange" as "additional include paths on "default.cwa". Without these I get many errors (expected), when adding it headers are normally found, but the quoted message stays (building in Debug). But I'll recreate the environment and try again...

Retested with current version and full paths: works.

Note: I have GnuCOBOL runtime compiling now (with the patched mpir gmp.h and one additional definition for timezone/daylight/tzname using an underscore) - only missing part there is linking (I'd like to use the VC generated dlls/libs), but I guess we get this working, too...

GitMensch commented 6 years ago

... or not... I'm really confused.

Given the layout

x:\project --> headers here x:\project\source1 x:\project\source2 x:\project\build --> more headers here x:\project\build\ocide --> project.cwa and source1.exe.cpj and source2.exe.cpj here

How should the additional include paths be set?

I've tried (on project.cwa):

None of these worked ?!?

LADSoft commented 6 years ago

it does work... you should use ..\..;.. although I agree I had problems too at first :)

when I tried to duplicate this issue I forgot to uncheck the 'create new directory for project' checkbox and so it created a nested directory... under THAT scheme I would have had to use ..\..\..;..\.. to make it work.

Because all this is confusing under your use case I did some checking as to whether the compiler should look for include directories relative to where the compiler finds the source file... but the microsoft compilers at least take it relative to the CWD when the compiler is invoked (which OCIDE sets to where the project file is) so the behavior is going to stay...