-
Notifications
You must be signed in to change notification settings - Fork 21
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
programatically launching the idf environment #242
Comments
I thought this was just a hash of the build environment, but ...,
Looks suspiciously like a prefix. I can launch |
Dunno if this helps but |
I've got a closely related issue as you. I need a desktop shortcut that will set up idf.py, then run
|
i started working on getting this going again and now when I run the export.bat script it is telling me that I need to run the install.bat script to setup the venv which I did and it set everything up for Python version 3.8 but the export script is looking for python 3.10 |
Seems like we need a compatible git and python in our path first. It is possible to locate them both with c:\espressif\esp_idf.json, but I hard-coded these into the bat file for now: SET "PATH=C:\Espressif\tools\idf-python\3.11.2;%PATH%" |
What I have discovered with this is the expectations of a compatible python path being set. Because a user is able to install multiple copies of Python and the versions in those installations can be different using the path statement or the "PYTHONPATH" environment variable is not the best way to detect Python installations. The windows registry should be checked and the installations of python should be enumerated to see if there is a compatible version installed and the installation paths checked for the existence of the python executable. When dealing with the Windows operating system no assumptions should ever be made. The Windows installer does a horrible job at making sure a program cleans up properly when it is uninstalled which ends up leaving invalid entries all over the place. Those entries can be environment variables and also registry entries alike. Some users will also simply delete a program and not uninstall it and this causes issues as well. Developers will typically have multiple versions of a programming language/compiler installed and to assume that the one that has been set to an environment variable is the only one available is not the right thing to do. Adding a small amount of code to look for compatible installations by means other than environment variables can save users from doing some hair pulling which a lot of times ends up in a bug report being made and that ends up wasting a lot of time when you add it up for the person responding to the bug report and the time the user has spent for each time it happens. 30 or so lines of code in the install.bat file would remove the issue. What I have not been able to wrap my head around is why go through all of this crazy work to use what could possibly be a flawed or tainted python installation that is on the users machine instead of just downloading a clean packaged python that has everything installed into it that is known to work properly. The only way to make sure that there is not going to be any issue is when using something that has a known state and is guaranteed to be the same no matter where it is running. The other things is the reliance of old and outdated features inside an OS in order to get it to behave like a Posix system. DOSKEY is literally 40 years old. There is no API to access it from anywhere in Windows except for stdin at a cmd shell. The use of it forces the creation of a new application window with the cmd shell instead of a user being able to build using something like Microsoft Terminal. |
OK so this is the skinny, I have been working ona more complete binding of LVGL and MicroPython and one of the larger goals is to simplify compiling it. To do that I have written a python script that is the entry point for compiling. Bump in the road I am running into is getting things to compile on Windows. macOS and Linux are both good. Setting up the build environment in Windows has been a real thorn in my side.
I need to be able to set up the build environment by running an executable, batch file, script, etc... from the command line. It cannot launch another cmd shell that has the environment in it. It needs to set up the environment in the currently running cmd shell.
Alternatively I can run a command without using the cmd shell if it acts in the same manner as the cmd shell.
It would makes things easier if I was able to pass a command to execute if what is being run is a cmd shell. Doing this would require the forwarding of stdout to the cmd shell that executed the command.
I have not seen the ability to do this. I have looked at the lnk file that gets created to launch the build environment..
and I am thinking that
e67fc3a73fc75eba5dda3e96918109e6
is not going to be a constant. it will be different on each machine that the toolkit gets installed on... If that is the case then I am not able to programmatically create a build environment.The powershell lnk file shows a completely different series of numbers
This is what leads me to believe that the numbers are generated at installation time and would different for each install.
Another issue is not all of the SOC's are selected by default and i don't see any command line parameter for the installer to specify which SOC's are wanting to be used. I do not know if that is only for the purpose of setting the target or if the installer does other things as well.
The text was updated successfully, but these errors were encountered: