Support base file names with dots

[rochus-keller]

This is the replacement for https://github.com/LADSoft/OrangeC/pull/1032 in the hope that the windows build now works or is at least easier to fix.

[rochus-keller]

The issue seems to be connected with the windows build, because the commit only includes a few ifndefs and the build sees the original code unless ORANGE_NAMES_WITH_DOTS is defined.

Somehow the build seems to be lost in file comparisons until someone pulls the plug:

.....
Comparing files 00211.tst and 00211.C.EXPECTED
FC: no differences encountered

    occ /! /D__ILP32__ /D__noinline__=__stdcall__ 00212.c
    00212.exe > 00212.tst
    fc 00212.tst 00212.c.expected
Comparing files 00212.tst and 00212.C.EXPECTED
FC: no differences encountered

    occ /! /D__ILP32__ /D__noinline__=__stdcall__ 00217.c
    00217.exe > 00217.tst
    fc 00217.tst 00217.c.expected
Comparing files 00217.tst and 00217.C.EXPECTED
FC: no differences encountered

Error: The operation was canceled.

[LADSoft]

i was busy with mothers day and then rewriting, so i only saw this now.

I think I will forego this....

don't get me wrong I do appreciate your efforts on this as it highlighted a bug and showed there was a better way to do things, it is just you are floundering with changes that have nothing to do with what you really want to be working on, and meanwhile I've rewritten it at this point in a way that I think will work for both of us...

so I checked it in a few minutes ago. There were five checkins total I think you want to review the first one for your general compiler changes (I also modified your BUSY file here so definitely review that I did it right lol) and review the second one for the .dot. changes in the compiler proper.

[rochus-keller]

it is just you are floundering with changes that have nothing to do with what you really want to be working on

That's not true; if your compiler is not able to handle file names with included dots, I cannot use it and thus it wouldn't make sense to do what I planned. However, I wanted to help to make this function available and not just give you more work. As it stands right now, my code would have worked, and it was the test itself that stopped for no apparent reason. However, if you have now implemented the function yourself, then so be it. The main thing is that it is available and working. But it would make sense to coordinate better.

[LADSoft]

ok sorry.... i only thought you might be getting vexed. But honestly it would have been better for me too if I let you handle it... it isn't like I'm not doing a lot of different stuff and any help I can get is a blessing... in the future I will try to remember that.

[rochus-keller]

I just tested your commit https://github.com/LADSoft/OrangeC/commit/d2eae439bfa64d4ceef3d5487081d7933dc56fb2 on my Debian x86 with my reference project (awfy.zip) and unfortunately it doesn't work.

It behaves the same as it did before https://github.com/LADSoft/OrangeC/pull/1032 (i.e. the files with dots in the name are created without suffix and thus the icf is overwritten by the icd). For the files with not dot in the base name both icd and icf are generated as expected though.

Having a look at your changes I think you should also change Utils::AddExt which does nothing as soon as it discovers a dot.

[LADSoft]

ok done.

[rochus-keller]

Thanks. I just tested again with commit 14c56e333794b8062f2005d1fc0007498bd1a747 on Debian 12 x86 and this time everything works as expected.

Then I also tested my awfy reference project on Windows, but got tons of errors and warnings. See the compiler output log: compiler_output.txt

This doesn't make sense to me since the same code works on Debian and also with MSVC and Clang. Unfortunately I'm not sure with which version of orangefront I made this test last time. So I will check with previous versions.

Also note that I tried to compile "Hello.c" on Debian, but just added "Hello" to the command line, and just nothing happened (i.e. it looked like success, but nothing was generated).

[rochus-keller]

Update: I think I found the problem; since the project includes a Math.h and we are on Windows and the standard library include is explicit, it gets mixed up with the standard library math.h.

I will rename the file an try again.

[rochus-keller]

Update: I renamed Math.h and now it works.

So we can close this pull request because it became obsolete.

[LADSoft]

ok glad you figured it out. I was gonna say, I only got two warnings out of the entire project when I compiled it, and they seem legitimate :smile:

There are -z (clanguage) and -Z (c++language) command line switches to set the system include paths so you can make the distinction between #include <> and #include "". the preprocessor will try the -I paths (and the current directory) first if you use "" or the -Z/-z paths first if you use <>. you pretty much have to use -z and -Z if you are using system headers that use include_next btw.

Another thing is the default configuration of occ is that if you make a file called 'occ.cfg' in the same directory as the executable it processes command line switches out of it... you can change the file stem in configx86.c... I put the -z and -Z switches there so it will find the includes without always having to specify them....

as far as the missing warning when you try to compile a file with an invalid/no extension... well i probably should have thought of that. The way it works for me is that the file gets passed on to the linker and then the linker complains about not finding it... but if you don't have a backend to pass it on to a linker that kinda breaks lol... you can intercept the exceptional file around line 1030 of osutil.cpp if you want to put an error in the front end...

[rochus-keller]

Thanks. I still have a lot to discover in OrangeC and am glad for the hints ;-)