-
Notifications
You must be signed in to change notification settings - Fork 109
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
esp32: system_architecture returns <<"Generic--">> #1371
Comments
So the documentation is not clear, or our implementation is wrong… it looks like this is returning the OS architecture as defined by the compiler… any of the platforms will report “Generic” if they are using neither X86_64 or ARM compilers. |
I should have said as defined by cmake configuration, not necessarily the compiler itself. |
Yeah, I cooked this up (from some of your code): src/platforms/esp32/components/libatomvm/CMakeLists.txt
which gives you: "riscv32-v5.3.2_210_g12938e511e_dirty-esp32c3" but it runs into build issue due to this "Generic" check AtomVM/src/libAtomVM/CMakeLists.txt Line 278 in 1ca523c
And I have a very limited understanding of the build system, especially across platforms.. but the utility of |
I don't think we want to chant the CMAKE_ configuration there, that would lead to build problems... but I believe we could add a separate definition for the compiler - like AVM_SYSTEM_PROCESSOR. |
That definition for Generic is important for all of the MCU platforms in the cmake configuration process, so we don't want to mess with that. |
This is also slightly related to PR #1117 which I closed. I didn’t feel like we ever came to a logical consensus on what the returns should be, and as you point out, is not frequently needed. |
erlang:system_info(system_architecture)
, seems off.https://www.atomvm.net/doc/main/apidocs/erlang/estdlib/erlang.html#system-info-1 :
system_architecture the processor and OS architecture (binary)
0.6.5 release image and also local builds return
<<"Generic--">>
on esp32.code search suggests it should return something like
<<"ESP_IDF-3.2-xtensa_esp32">>
The text was updated successfully, but these errors were encountered: