omake not using right path for self

[LADSoft]

I have the ORANGEC and ORANGEC_HOME environment variables set. Sometimes when I run omake it uses the wrong path for itself for nested calls.

as an example (using cmd.exe as the shell)

c:\OrangeC\tests>omake clean
        c:\OrangeC\tests\omake /Calexcs clean
'c:\OrangeC\tests\omake' is not recognized as an internal or external command,
operable program or batch file.

if i manually add a path to omake, e.g.

\orangec\bin\omake

then things work...

[LADSoft]

im generally not having luck with omake. I tried reverting the latest changes but still no luck. Basically, it won't compile the C runtime library no matter what I do (always problems with NULLDEV) and then the above problem is an issue too... I basically can't do anything with the main line because I can't build anything...

[chuggafan]

What your describing nominally sounds like changes I've made, as I did make that one change in #1060 however that should be getting the value from files[0] and feeding that into OS::AbsPath to fix a bug where trying to use \orangec\bin\omake would cause issues elsewhere that didn't handle those paths, since we could create a relative path and then not translate it into an absolute path, causing errors in the build, found here: #1060 (comment)

I think a solution to this is to detect if there's any attempts of a relative path being made (i.e. search the string for any instance of \ or /) and if we do have an instance of a directory separator, just run the OS::AbsPath then, otherwise leave omake unchanged (though that can also cause issues later on if multiple directories have a program called omake in it).

[LADSoft]

the problem with using argv[0] (which I assume is where files[0] comes from) is that it does not always have the full path that the executable ran from... especially on MSVC... so there has to be another way of finding out what the path of the running executable is....

[chuggafan]

argv[0] is the literal command being pasted in, so as long as the original command is the one that is being abspath'd then it's fine.
The issue is that when there's no path component the omake can come off of the %PATH% stack, which causes the failure.
That's why my suggestion is the check for a path component, if there's no path component, then we're getting omake off of %PATH% and (in theory) we can avoid doing abspath, of course, this runs into the issue of a sub-path having its own omake.exe which can cause havok.

If we truly want to fix this, at least on win32 (I'd have to think of the OS wrapper for linux), https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamew perhaps?

[LADSoft]

sorry i thought i answered this...

i think we have to fix this one way or the other... because right now if I go to any directory other than /orangec/src (for example /orangec/src/tests) and type omake, it tries to use omake in the current directory and since there isn't one the build fails... and we can't just leave it floating because a build script might modify path and then omake could be taken from the wrong path (there might be different omakes at different stages of development for example, or omakes from different versions of the compiler?

the most efficient way is to just ask the os for the file name but I realize that isn't portable. So a search through the path for the first matching file would be acceptable, but it should only be done in the case where there is no path component in argv[0] I guess....