RFC: Add setup command and provide .gitignore in template

[auxym]

Current situation:

• The template project created with piconim init does not contain a .gitignore file
• This results in commiting, by default, the C files generated by nim as well as the full pico SDK, which might not be desired
• The csource/build directory cannot be added to .gitignore, because it contains the Makefile, which is generated by cmake during piconim init. Thus, piconim build would fail on a fresh/clean repository.

Proposal:

• Add a setup (or configure, or init and rename the current init to create) command that runs cmake with the SDK path provided as an optional argument. This is automatically run during init
• Add a default gitignore file that ignores the entire csource/build directory as well as csource/*.c.
• Thus, a user could clone a "clean" repository that was created by piconim init, run piconim setup (optionally providing as SDK path), and build it with piconim build.

If the maintainers agree with the idea, I could put in a PR.

[beef331]

I do not see the purpose of the setup command, could you elaborate what it'd solve, the gitignore sounds fine though.

[auxym]

Right, so situation:

1. gitignore ignores csource/build
2. When I either run git clean, or clone the repo from scratch, csource/build won't exist
3. piconim build runs make in the csource/build directory and will therefore fail.

The proposed setup command would initialize csouce/build by running cmake, which is what init does currently.

The alternative would be to have piconim build run cmake each time. The problem I see with that is that you'd have to provide it with your pico SDK path each time you build, which can get annoying.

[beef331]

Ah I see, sounds fine to me then.

[beef331]

Now that I think about it though, could we not just emit a .gitignore in the directory when we copy?

[auxym]

I'm not sure I understand, could you elaborate on that? What would be the contents of the .gitignore file in that proposition?

[casey-SK]

I suppose we can store the piconim init arguments in a file, but without the csource, the only place to put them is in the project directory, which I wouldn't much like. So I suppose for this use case, the setup command sounds like the best option.

[auxym]

Well, we don't want to store the init arguments, because init is run exactly one when the project is created. Imagine the following use case:

1. I create a project using piconim. The sdk path points to my home dir (/home/francis/...).
2. I push said repo to github with some instructions for building.
3. Someone else clones it and wants to build. However, their sdk is at a different path, or they want to download it. What now?

Thus, my proposed setup command would allow the other person to set the SDK path for their build, and in the future other machine-specific options (sort of similar to "configure" scripts in good old C/make land).

Now, here, I proposed to also have setup run cmake, but given #33 I think the idea is to have build run cmake, since we would be dynamically modifying CMakeLists.txt (I propose generating an included file) on build.

I don't think we need or should ignore the full csource dir btw, only csource/build and some selective wildcards for generated files in csource (*.c, *.json). This would allow a developer to customize their CMakeLists.txt file and and keep it around. It just needs to include some files that are dynamically generated by piconim (calling the peripheral modules, etc).

[casey-SK]

I see what your getting at. Let me just chime in now and mention that I am a novice programmer, and most of my experience is in Nim and I know next nothing about writing and building programs in C. @beef331 seems to know a lot more than me haha. I created the piconim program by looking at the manual steps that we previously had to perform manually and automated it as best I could. It is clear now that I may not have been using the best practices when it comes to cmake. So I guess I would encourage you to take a look and see if you can improve upon it? and while your at it, make a setup command, lol.

I am also happy to try to implement it myself, if you provided some brief pseudo code to go off (since I am not experienced in building for C)

[auxym]

OK, I'll put in a PR as a proposal. Just waiting for @beef331 to clarify his previous comment.

[beef331]

You've sold me on the need for this, so seems fine, we can always change or remove features later if they're actually pointless.

[auxym]

Closed via #36