-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation of code outside of the Red/ path fails under Windows #366
Comments
It seems the problem is caused by your |
I tried again and checked that test.exe was not running. I guess the problem is the Red/System compiler trying to write to the program files directory. But why does it do that? I'll show the full console log:
|
Thanks, I will investigate that further. |
The error message is caused by Windows forbidding to write to ProgramFiles folder. Beyond that, I cannot reproduce your problem:
You would need to put some PROBEs in %rsc.r and %compiler.r to see where Red/System does select such target path. |
From a quick look at the source and a quick test, I'd guess the issue is line 101 in red.r: opts/build-prefix: system/options/path I'm guessing that you are running Rebol from the Red directory and so don't hit the problem. The program compiles if I specify the output file. This console session
|
Sorry I clicked the wrong button :-( If the fix is tricky, it's no problem for me to copy REBOL into the Red directory. |
No, I run REBOL from %/c/dev/SDK/tools/. |
Could you please re-test this issue with the last fixes from |
I get this error on the fix-issue-277 branch:
Works on OS X |
I have fixed this internal error. Now you should have a proper "Cannot access source file" error message. |
Yes I now get the "Cannot access source file" error:
The compiler is now using the directory of the REBOL executable as its base directory, previously it could find the source but was trying to write the Red executable to the directory of the REBOL executable. There is a simple workaround which is to use the fullpath of the source. It then demonstrates the issue with the Red executable:
Again, there is a simple workaround to specify the location of the executable:
I can happily live with the workarounds at this stage. |
If I understand correctly, the remaining problem is now due to differences between running the compiler via an OS command-line ( |
Basically yes. But my own tests seem to show that some cases are still broken, I need to do more tests after solving this "command-line vs console" paths mismatching. |
If we can't come up with a safe heuristic to detect run-script: func [script [file!] args /local p r] [
p: copy system/options/path
system/options/path: what-dir
r: do/args script args
system/options/path: p
r
] |
It seems that |
Peter, could you give it a new try with the latest commit from |
I've tested with the latest commit on the fix-issue-277 branch butI'm afraid that I'm still getting the cannot access source file error:
If I change lines 101 & 121 of %red.r to use system/script/path then it works just fine. I also tested compiling the same test program from the command line under both Ubuntu and OS X, again it worked. I ran the complete test suite successfully with these patches in all three environments, Windows from the REBOL/View console, the others from the command line. |
Thanks Peter, I will test your fix here, that might just be the right trick to finish this series of path fixes. Actually, |
Nenad Your change also needs to be applied to line 121:
|
I saw that (too late), so I have pushed a new commit just now for that. Thanks for noticing. |
I'm still getting the cannot access source file error. The 'ANY isn't working as expected because system/options/path is set to the dir of the REBOL executable (It seemed to be 'NONE before but I guess that must have been some unintended side effect). I've added some debug prints to show the effect of the inserted call of 'ANY:
I always seem to have problems with file paths in REBOL, I hope I'm not a jinx on them. |
Hmm, I don't think that
(I think the current |
Right Andreas, that shows you how confused I am with all the REBOL system paths and their confusing names... |
Andreas, have you find use-cases, where |
Andreas, with your proposed fixed, the following use-case doesn't pass anymore:
It still passes when run from console with:
EDIT: sorry, I've inverted the test cases results, it's now in the right order, the one failing is the one from the console. |
Ok, it seems the only solution to overcome the REBOL internal bad working dir issue is to re-sync with OS path in order to compensate for REBOL's internal "cd" when DOing a script. I will test that solution tomorrow. |
Changing line 99 of red.r as below fixes the problem for me. I've tested under Windows 7 (REBOL/View console). Ubuntu (command line) and OS X (command line). Also run-all.r continues to work after the change. from base-path: any [system/options/path system/script/path] to base-path: either any [
system/options/path = none
system/options/path = first split-path system/options/boot
][
system/script/path
][
system/options/path
] It's a little verbose. Testing system/options/path = none may not be strictly necessary. |
Hah! R2 has I did the following tests using R2/Core 2.7.8 on Linux:
So the fix would just be to use |
The change that I suggested works in the REBOL console under OS X and Liunx provided that the pwd isn't changed by change-dir in the REBOL console session ... so it doesn't really work :-( I'll test Andreas fix. |
I've tested Andreas's monumental discovery and resultant fix and found that it works in the following situations: Windows REBOL console The change has no adverse affect on run-all.r |
As it really seems to work in all cases tested so far, I tentatively pushed a |
Andreas, your fix works well with all my test cases. Great job! Thank you very much for your help! |
Fixes following issues: #251 (Red doesn't find source in working directory) #252 (#system cannot find #include) #277 (Include system doesn't handle well files with same name in different directories) #366 (Compilation of code outside of the Red/ path fails under Windows) #381 (#system-global doesn't detect equal #include paths)
When compiling code outside of the Red/ path under Windows, the compilation from Red/System to machine code fails.
Code
Output
The text was updated successfully, but these errors were encountered: