search

blitz-research / monkey2

zlib License
132 stars 44 forks source link

Incorrect build error with linking [Blocker] #349

Open XANOZOID opened 6 years ago

XANOZOID commented 6 years ago

File doesn't exist in build - but it does

Error Message

....
error: error opening './obj/local/armeabi-v7a/objs-debug/mx2_main/__/__/__/__/__/__/__/Monkey2-vGIT/monkey2/modules/stb-vorbis/stb-vorbis.buildv1.1.10/android_debug/include/_r.o.d': No such file or directory

1 error generated.

make: *** [obj/local/armeabi-v7a/objs-debug/mx2_main/__/__/__/__/__/__/__/Monkey2-vGIT/monkey2/modules/stb-vorbis/stb-vorbis.buildv1.1.10/android_debug/include/_r.o] Error 1

....

Why it is happening:

  1. The module which is reportedly missing is not actually missing
  2. The code can compile in one folder, but not the other
  3. Shorter paths did not generate this error, longer paths did

Problem: Long filenames are the problem. When the build process attempts to copy module files with long names, the OS fails to copy and thus this error persists.

Semi-related to #341

blitz-research commented 6 years ago

Please describe how I can reproduce this, eg: where your monkey2 install is located, what I should do to cause the error to happen etc.

An error message is nice, but without some way to reliably reproduce that error message on my machine there's very little I can do.

On Wed, Mar 7, 2018 at 1:59 PM, Abe King notifications@github.com wrote:

File doesn't exist in build - but it does Error Message

.... error: error opening './obj/local/armeabi-v7a/objs-debug/mx2_main///////__/Monkey2-vGIT/monkey2/modules/stb-vorbis/stb-vorbis.buildv1.1.10/android_debug/include/_r.o.d': No such file or directory

1 error generated.

make: *** [obj/local/armeabi-v7a/objs-debug/mx2_main///////__/Monkey2-vGIT/monkey2/modules/stb-vorbis/stb-vorbis.buildv1.1.10/android_debug/include/_r.o] Error 1

....

Why it is happening:

  1. The module which is reportedly missing is not actually missing
  2. The code can compile in one folder, but not the other
  3. Shorter paths did not generate this error, longer paths did

Problem: Long filenames are the problem. When the build process attempts to copy module files with long names, the OS fails to copy and thus this error persists.

Semi-related to #341 https://github.com/blitz-research/monkey2/issues/341

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QvD1aJ_YatWi-0OLSPq14EYQe4E6ks5tbzDqgaJpZM4SfsN1 .

XANOZOID commented 6 years ago

@blitz-research Sorry, no problem!

Details

Steps to reproduce:

  1. You can see that the template file compiles in a directory with a short name example: C:\ProgFiles(x86)\Monkey2-v1.1.08\_Projects\test

  2. To see that somehow it breaks, just keep on making the name of the folder longer (emulating a deeper folder hierarchy) example: C:\ProgFiles(x86)\Monkey2-v1.1.08\_Projects\test_with_a_longer_name

  3. If you've made your folder name/file hierarchy deep enough, it should generate this (semi-incorrect) error.

XANOZOID commented 6 years ago

Sorry about the late response! This was indeed the file path which caused the linking (copying) error:

C:\ProgFiles(x86)\Monkey2-v1.1.08\_Projects\test_with_a_longer_name\test_display.monkey2 (where test_display.monkey2 is the simple mojo app)

This was a test I made, of course. The real structure was not much different, at all, actually, but I've since done some path refactoring to shorten everything as much as I can.

So that's all it really took to make the error occur, unfortunately. And, yes, I do recall having some file path length errors with Node.js fairly frequently.

Just out of speculation, I find that it is the files being copied over to the project that is absurdly long . . . Maybe a solution would be to just make module names very short and serialized at the expense of human readability for the file names?

blitz-research commented 6 years ago

This was indeed the file path which caused the linking (copying) error:

Yes, I noticed that after my last post - will have a hack at this soon.

I find that it is the files being copied over to the project that is absurdly long

Which files being copied over to the project?

On Thu, Mar 8, 2018 at 4:37 PM, Abe King notifications@github.com wrote:

Sorry about the late response! This was indeed the file path which caused the linking (copying) error:

C:\ProgFiles(x86)\Monkey2-v1.1.08_Projects\test_witha longer_name\test_display.monkey2 (where test_display.monkey2 is the simple mojo app)

This was a test I made, of course. The real structure was not much different, at all, actually, but I've since done some path refactoring to shorten everything as much as I can.

So that's all it really took to make the error occur, unfortunately. And, yes, I do recall having some file path length errors with Node.js fairly frequently.

Just out of speculation, I find that it is the files being copied over to the project that is absurdly long . . . Maybe a solution would be to just make module names very short and serialized at the expense of human readability for the file names?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-371368295, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QrVurpFz4EZ4W-XLySrxtNp-4IHHks5tcKdzgaJpZM4SfsN1 .

XANOZOID commented 6 years ago

Actually, it isn't absurd like I wrongfully said, it's just very detailed, the file has a lot of information to it - to the point where this kind of bug happens with even relatively small file paths.

  1. The files being imported from the module have very long descriptive names
  2. Debug mode adds even more context to the filename
  3. The build directories add length on top of that!

Example: image

blitz-research commented 6 years ago

Latest version in develop should improve this considerably. Note you'll need to rebuildall2go.

On Thu, Mar 8, 2018 at 8:52 PM, Abe King notifications@github.com wrote:

Actually, it isn't absurd like I wrongfully said, it's just very detailed, the file has a lot of information to it - to the point where this kind of bug happens with even relatively small file paths.

  1. The files being imported from the module have very long descriptive names
  2. Debug mode adds even more context to the filename
  3. The build directories add length on top of that!

Example: [image: image] https://user-images.githubusercontent.com/29788070/37139372-e14c7040-226a-11e8-9773-1d27289b9e39.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-371408080, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QhHtJyc1sVi0mn87mWAyVE-97Lznks5tcOMhgaJpZM4SfsN1 .

XANOZOID commented 6 years ago

Thanks, Mark! I was waiting to see what you had to say if you had finalized your solution and I have been using it since you've posted the update. The shortening code seems to be doing a great job!

I must note that I tested to see what it would do with a project I had cloned off GitHub to my GitHub folders location and it gave some strange errors.

This is the file path: C:\Users\skeyt\OneDrive\Documents\GitHub\Monkey2examples

Error

I'll post the error below:

Build error: System command failed:

cl -c -EHs -W0 -MT -utf-8 -O1 -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/monkey/native" -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/freetype/freetype-2.6.3/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/openal/openal-soft/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/sdl2/SDL/include/" -DBB_NEWREFLECTION -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/" -showIncludes -Fo"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/r5b58089e.cpp_r.obj" "C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp" >tmp/stdout1.txt

_r.cpp
C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp(10): fatal error C1083: Cannot open include file: 'Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example_Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example.h': No such file or directory

Microsoft (R) C/C++ Optimizin

Here's an image of what the file output looks like image

Extra Info

This repository I got it from, which is pinned on the forums, has incredibly long names and I assume that a lot of people will come across this repository in hopes to learn more about the language. . . . This is obviously an extreme example and, generally, people making their own projects would not be naming their files this way at all (hopefully). But as you can see, the path length for these projects are doubled in length. Likely not to be a problem for most projects as the entry file is something under 10 or 12 letters.

What do you think? Experienced developers will be able to spot this right away and fix/report it, but newcomers (or users without lower level language experiences) may be (upset?) confused!

Possible next step?

If possible, I don't necessarily believe you should have to start serializing user filenames, but would it be possible to link using relative names instead of full paths? That might be the next best move here. . .

Thanks for the fixes so far, Mark!

blitz-research commented 6 years ago

Is this a new bug since latest fix or has it always happened?

If it's always happend, please create a new issue.

On Sun, Mar 11, 2018 at 1:14 PM, Abe King notifications@github.com wrote:

Thanks, Mark! I was waiting to see what you had to say if you had finalized your solution and I have been using it since you've posted the update. The shortening code seems to be doing a great job!

I must note that I tested to see what it would do with a project I had cloned off GitHub to my GitHub folders location and it gave some strange errors.

This is the file path: C:\Users\skeyt\OneDrive\Documents\GitHub\ Monkey2examples Error

I'll post the error below:

Build error: System command failed: cl -c -EHs -W0 -MT -utf-8 -O1 -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/monkey/native" -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/freetype/freetype-2.6.3/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/openal/openal-soft/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/sdl2/SDL/include/" -DBB_NEWREFLECTION -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/" -showIncludes -Fo"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/r5b58089e.cpp_r.obj" "C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp" >tmp/stdout1.txt _r.cppC:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp(10): fatal error C1083: Cannot open include file: 'Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example_Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example.h': No such file or directory Microsoft (R) C/C++ Optimizin

Here's an image of what the file output looks like [image: image] https://user-images.githubusercontent.com/29788070/37248014-830f041e-2483-11e8-837c-12a12ebc5779.png Extra Info

This repository https://github.com/Pakz001/Monkey2examples I got it from, which is pinned on the forums, has incredibly long names and I assume that a lot of people will come across this repository in hopes to learn more about the language. . . . This is obviously an extreme example and, generally, people making their own projects would not be naming their files this way at all (hopefully). But as you can see, the path length for these projects are doubled in length. Likely not to be a problem for most projects as the entry file is something under 10 or 12 letters.

What do you think? Experienced developers will be able to spot this right away and fix/report it, but newcomers (or users without lower level language experiences) may be (upset?) confused! Possible next step?

If possible, I don't necessarily believe you should have to start serializing user filenames, but would it be possible to link using relative names instead of full paths? That might be the next best move here. . .

Thanks for the fixes so far, Mark!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-372078134, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QvkP7MxLvLbWqaprddyWt8VpUoA-ks5tdGxPgaJpZM4SfsN1 .

blitz-research commented 6 years ago

Can reproduce and am pretty sure it's a different issue, but I should be able to do something here too. Still, those filenames are too long IMO, and will likely give problems one way or another eventually.

On Sun, Mar 11, 2018 at 2:04 PM, Mark Sibly blitzmunter@gmail.com wrote:

Is this a new bug since latest fix or has it always happened?

If it's always happend, please create a new issue.

On Sun, Mar 11, 2018 at 1:14 PM, Abe King notifications@github.com wrote:

Thanks, Mark! I was waiting to see what you had to say if you had finalized your solution and I have been using it since you've posted the update. The shortening code seems to be doing a great job!

I must note that I tested to see what it would do with a project I had cloned off GitHub to my GitHub folders location and it gave some strange errors.

This is the file path: C:\Users\skeyt\OneDrive\Docume nts\GitHub\Monkey2examples Error

I'll post the error below:

Build error: System command failed: cl -c -EHs -W0 -MT -utf-8 -O1 -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/monkey/native" -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/freetype/freetype-2.6.3/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/openal/openal-soft/include/" -I"C:/ProgFiles(x86)/Monkey2-vDEV/monkey2/modules/sdl2/SDL/include/" -DBB_NEWREFLECTION -I"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/" -showIncludes -Fo"C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/build/r5b58089e.cpp_r.obj" "C:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp" >tmp/stdout1.txt _r.cppC:/Users/OneDrive/Documents/GitHub/Monkey2examples/Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/_r.cpp(10): fatal error C1083: Cannot open include file: 'Example - Bresenham Line algorithm - code example.buildv1.1.11/windows_debug_msvc_x64/include/Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example_Example_4_5_4Bresenham_4Line_4algorithm_4_5_4code_4example.h': No such file or directory Microsoft (R) C/C++ Optimizin

Here's an image of what the file output looks like [image: image] https://user-images.githubusercontent.com/29788070/37248014-830f041e-2483-11e8-837c-12a12ebc5779.png Extra Info

This repository https://github.com/Pakz001/Monkey2examples I got it from, which is pinned on the forums, has incredibly long names and I assume that a lot of people will come across this repository in hopes to learn more about the language. . . . This is obviously an extreme example and, generally, people making their own projects would not be naming their files this way at all (hopefully). But as you can see, the path length for these projects are doubled in length. Likely not to be a problem for most projects as the entry file is something under 10 or 12 letters.

What do you think? Experienced developers will be able to spot this right away and fix/report it, but newcomers (or users without lower level language experiences) may be (upset?) confused! Possible next step?

If possible, I don't necessarily believe you should have to start serializing user filenames, but would it be possible to link using relative names instead of full paths? That might be the next best move here. . .

Thanks for the fixes so far, Mark!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-372078134, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QvkP7MxLvLbWqaprddyWt8VpUoA-ks5tdGxPgaJpZM4SfsN1 .

blitz-research commented 6 years ago

Actually, it is the same issue reallly, don't bother creating a new one, more fixes to come!

XANOZOID commented 6 years ago

@blitz-research Sounds good to me! I wasn't too sure myself and I can safely say that yes the error happened after the fix - unless you posted one mere minutes before you mentioned it!

blitz-research commented 6 years ago

Well, that's a little surprising as it should have nothing to do with the fix!

I'll look into it thoutgh...

On Sun, Mar 11, 2018 at 4:09 PM, Abe King notifications@github.com wrote:

@blitz-research https://github.com/blitz-research Sounds good to me! I wasn't too sure myself and I can safely say that yes the error happened after the fix - unless you posted one mere minutes before you mentioned it!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-372085869, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3Qm67vrk--OuJdbloJsej6cu_2TYKks5tdJV-gaJpZM4SfsN1 .

XANOZOID commented 6 years ago

Sorry, the fix you made is indeed unrelated to the error that was produced!

blitz-research commented 6 years ago

Wel, that's kind of good news - I can go ahead with the v1.1.11 release tomorrow! The fix for this will have to wait a bit though...one major breaking change at a time!

On Sun, Mar 11, 2018 at 5:06 PM, Abe King notifications@github.com wrote:

@blitz-research https://github.com/blitz-research sorry, the fix you made is indeed unrelated to the error that was produced!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/349#issuecomment-372087772, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QmFtW1n2FnwdDy5xeKACbDgBSQ8mks5tdKKxgaJpZM4SfsN1 .