Okay, no rush on GitHub stuff. Most of us have these pesky day-jobs we need to keep doing.
Yeah - the repository at the moment looks like an examples project and not a library project. We need to shift the focus to, "This is a library and here are some examples" rather than "Here are a bunch of examples, and oh-by-the-way, there is a library hidden somewhere in here."
Once we have a docs section, I was wondering about putting something together on how to contribute. (DEVELOPMENT.md) or (CONTRIBUTE.md) so we have some rules laid out on what we expect from pull requests before they will be considered. I could probably benefit from a bit of guidance here too. Like how about testing... I'm not suggesting we invest load of hours into GitHub Actions and continuous integration or anything, just that the person raising a PR should include at least one example of how to test the change and some assertion that it worked for them.
If we do separate the library source into different files based on prefix, would it make sense to have a folder for source and another for headers? Like this?
Code: Select all
That way when we compile, we can pass in the -I path/to/include and not have to specifically path the includes in our software. That would also make your examples a little more portable. A person could take your template and build it anywhere without having to edit the paths to the headers in the top of their source code.
I know that the .h and .c files can be together in the same folder, but I am just going on other conventions I have seen.
With regards to assembly in separate files: Is there much benefit to having the assembly inline? I know you talked about this in one of your videos but, I don't remember the reasoning.
I just figured, that if we add the assembly files to the compile command, they will be compiled and linked together. I have tried this with z88dk and it's fairly straight forward, but not - as you say - very beginner friendly. So perhaps I am being a bit too pedantic on how to structure a library. I am used to working with Make, and Make is designed for automating all of that stuff to the point where you stop thinking about it.
BTW - I am already loving this long-format, asynchronous channel to discuss things like this. Well done to you and Leo for getting this forum stood up.