espup: implement stable symlink to the libclang location #319
Comments
|
Did you forget to run |
|
And by the way, and because you mention again how helpful Rust is
... well, this panic is coming from Rust bindgen. And it is extremely unhelpful. Yeah, it is not us. I'll think how (actually if possible at all) to capture this panic and print something meaningful. The crux of the problem is that you are running the wrong Clang (your system one), which does not know that "xtensa" arch exists, as the xtensa arch is not upstreamed yet - neither in Rust, nor in Clang (as these share a common backend - LLVM). The other problem you complained about in that other thread (the env vars thing) is also an upstream problem - in So where I'm getting at is that the build is complex, but it is not always us. :) |
|
@MikeMitterer |
|
Only @SergioGasquez This is really a total PITA. Remember this? |
I'll probably bring this for discussion on the next meeting (if I'm able to attend, that is). Or at least leave a reminder about it in the Discussion notes. I mean, I can try to check for the xtensa Clang lib being on the path when building |
|
Aaaargh.
Just doing
|
Yes, this was always the case.
I won't be able to attend the meeting as its bank holiday in Spain, but we can have the discussion on the meeting notes. I am not against modifying the user Again, this would be much simpler once we can use LLD as linker for no_std builds. (esp-rs/esp-hal#357) |
|
For |
|
Right, not sure if you know, and also its definitely not a solution but something that can simplify stuff for std ONLY users, is using the |
This is not simplifying anything. We don't use the espup GCC, and we don't care about it, in the path or not. What we need is ONLY the |
|
And by the way, at the very least we should be improving the message
|
But even if espup GCC is not used, is still downloaded and installed by espup unless you used that flag. I think setting
The message saying that you need to source the export file is a warn, this is the usual output in Unix: Also, in all the installation guides, we mention that Unix users must source the export file, not sure how this can be improved, any suggestion? |
|
But it's a bunch of logs still. Why? This is not a service or a firmware. Look at |
|
Here is the output of doing I created esp-rs/espup#375 with some changes to the logs and here is what the output of this branch looks like: |
|
Also, I opened esp-rs/espup#373, which simplifies the amount of environment variables that we need to set up. This would be the resulting We can continue the discussion on the community meeting, but I am happy to set up those variables in |
This is a great improvement, thank you! Would it be possible to put the "To get started, you need..." text as the last step / log in the sequence? Basically after "Installation successfully completed!". This way - and similarly to I guess I'm nit-picking (removing the timestamp was already a big improvement), but do we need the icons? They look cool, but are yet another distraction imo. And |
That would be absolutely great, but I suggest rather than putting the variable in |
|
@SergioGasquez How about the following alternative proposal that completely bypasses altering the user's environment:
This way we kinda get the best of both worlds:
Might even work on Windows? Not sure we can symlink there these days? Sure, |
Thanks for the feedback! This is how it currently looks like: Will think about removing the emojis and the environment variables next week (I'm on vacations until then). And thanks again for all the alternatives! |
|
@ivmarkov F... + SORRY because of another problem @ALL here in the discussion - Thanks! It's really cool to see how you improve the logs and the whole environment to make the Rust environment, and it's toolchain even more helpful!!!! |
Seems like symbolic links require admin privileges / developer mode on Windows. Well I guess on Windows the no? |
ivmarkov
changed the title
|
(Will keep this open, but renamed the issue to reflect where we got after discussing.) |
Windows should have this issue already solved, we don't need to source the
Even when we use LLD as linker, we would still need Here is how |
OK, fine. I don't like it because we then do different things for different OS-es, but even if we have the symlink for non-Windows first, that would be a step forward.
No. The idea of the symlink is that If you don't like the symlink idea - fine - just modify the user's env on ALL operating systems. Even though this is polluting the user env, which was the primary reason I came up with the symlink idea - it is something ONLY But having this "sourcing" for non-Windows is really, really hurting the initial user experience. I absolutely want to avoid this extra step - one way or the other. |
|
Im just working on releasing |
Sounds great. If you would like to minimize any changes / impact, we can have the symlink in addition to / without retiring the export file for now. That would be enough for |
|
Hi! I've been working on this the last few days, and I've come up with two PRs: Let me know your thoughs, I definitely prefer setting user environment as it will solve the issue for both approaches, and it basically mimics what |
|
My 2c: The reason why I suggested the symlink approach in the first place - for both Windows and ?nix though - is because - in the shiny new world where So why bother doing rocket science with detecting user shell and whatnot given that this effort will not pay off anymore in the near future? YAGNI. With that said - as long as I don't have to do the |
Thanks for your input! Since it seems like there are some progress on LLD side, we can go with the symlink approach, and if we still see some areas for improvements, we can reevaluate later. Just to recap, here is how it would like for the different approaches/OSes:
|
|
Please hold on for a sec. I'm just debugging an issue, where the build for If I can't workaround this by - say - somehow re-ordering the |
|
@SergioGasquez TL;DR: False alarm. Turns out ESP IDF Yet - and a bit weirdly - ESP IDF builds tries to use the old GCC toolchain (and fails, as it is not compatible with the ESP IDF Now, since |
|
@SergioGasquez I've implemented the symlink support here. Let me know in case you change the symlink name and location in the final Note that the symlink approach will also run on Windows, where the symlink might not be available, but then why not? User might want to set it up himself there, instead of polluting his environment env. |
Great, I will do some testing with esp-rs/espup#380 and using the |
|
Update: Just did some testing, and I was able to build an Just merged the esp-rs/espup#380 PR! |
|
I think we can now close this issue! |
|
A new release of |
I followed the instructions on https://github.com/esp-rs/rust-build and made a project with:
No mater if I compile with
cargo buildor if I usecargo espflash save-image --chip esp32 testI get the following error message.
Rust is know for it's helpful error messages but in this case I get a bunch of messages but I don't know what they want to tell me...
A bunch of Env-Vars, CMake-Vars bla, bla, but what is right and what's wrong in this incredible complex build environmen????
The last lines of the error message shows that some flags are wrong or missing - OK, maybe, but where should I set the flags?
Please help!
The text was updated successfully, but these errors were encountered: