Importing project adds extra incomplete lines in CMakeLists.txt

[maqifrnswa]

Describe the bug
Importing project adds extra incomplete lines in CMakeLists.txt that will cause builds to fail. This was observed on 4 different Apple silicon macbooks out of a class of 65.

To Reproduce

1. Create a minimal project (e.g., "Create C project" with just Console over UART)
2. Delete .vscode, .build, .gitignore, pico_sdk_import.cmake.
3. import the project
4. there will be extra mangled lines in CMakeLists.txt that cause builds to fail

Expected behavior
Those extra characters shouldn't be there

Screenshots
Photo from a student's computer. 4 different students observed the same behavior.

Platform (please complete the following information):

• OS: macOS
• Architecture: Arm64

Additional context
Maybe the original content is longer than the new content - so the old content is being written out even though it should be done?

pico-vscode/scripts/pico_project.py

Line 802 in 18046ae

file.write(content)

[will-v-pi]

Maybe the original content is longer than the new content - so the old content is being written out even though it should be done?

Can confirm this is the issue - fixed now

2. Delete .vscode, .build, .gitignore, pico_sdk_import.cmake.

Why are you doing this step? It should not be necessary to delete any of these files to open a project on a new machine, the only current known bug with them is #206 which can be manually fixed by just updating that version.

[maqifrnswa]

Thank you! That's awesome!

2. Delete .vscode, .build, .gitignore, pico_sdk_import.cmake.

Why are you doing this step? It should not be necessary to delete any of these files to open a project on a new machine, the only current known bug with them is #206 which can be manually fixed by just updating that version.

Yes, #206 is why I was having students do that. From my experience, it's hard getting dev environments on >50 machines with different architectures and OSes all working properly with an embedded system ecosystem, so once one has a working set up, I want to keep using that until students are more comfortable changing things manually. (I've taught classes with as many as 120 in it, so consistent dev environment management is a huge deal in those classes!) There's a wide range of experience in the class from high to relatively new experience. Since this is the first week of class, I wanted uniform instructions that would "just work" on all machines regardless of which SDK. The easiest way was to let the "Import Project" rebuild those files based upon whatever SDK they have that already works.

Why I avoided installing new versions of SDKs: I've seen that sometimes, when downloading and installing a new SDK version, something happens where some files are missing. It happens ~5-10% of the time, and I guess it's because the download got interrupted. Last year, a new version of the SDK was released the day before a project was due. Many students that downloaded it had this issue (~20% of the class), and suddenly none of their code worked anymore. Before students know how VS code works, it's kind of an undebuggable bug (from their point of view, they don't know how to debug VS code extensions yet, we're just learning the C side). All they have to do was downgrade to the old version or go in and delete that version of the sdk from their machine and have it restart the download, but debugging VS code itself is outside of the scope of the class and students were confused as to why their machine had a problem and their classmate who did identical steps did not. In the meantime, they are lost and can't do anything. I'm trying to avoid extra, unique steps that only some students have to do. Once a student has a working environment, I want to use that version.