Never mind; I misread what Octocone had written. I apologize for the accusation.
However, his point - that the include directory has source code in it - is still salient, even if the 'rule' is less cut and dried. It is up to you how you organize your source code directories, but it is going to confuse people trying to help you if you have a directory marked 'include' that contains the source code as well as the headers. This is something that was pointed out more than one before, and while you are free to do what you choose in that regard, it is going to make it difficult for the rest of us to help you, if only because it is confusing.
The usual practice is to have all (or at least most) of the header files in a single
include directory, and have the code that corresponds to them in a separate hierarchy under something such as
src. This would give something like:
Code: Select all
/dixium
LICENSES
README.md
/include
stdio.h
string.h
vga.h
/src
linker.ld
/boot
boot.S
kernel.c
/kbd
kbd.c
/tty
tty.c
/doc
Noiw, you don't
have to follow this layout; it is a Common Practice adopted by most others, and unlike a Best Practice, it is based on conventional rather than from any pragmatic need. However, following a Common Practice eliminates the need to explain why you did something one way an not another; it makes things simpler if you do it, at least for the people who are trying to help you.
The practical upshot of this is that, while you don't necessarily need to
justify the decision to break a Common Practice (as you would when breaking a Best Practice), it would really help if you at least
explained the model or pattern you are using.
On a side note: it doesn't look as if you have been checking in changes to your code. Generally speaking, any time you have a change to your code, even if it isn't complete, you want to check the change into the repository when you stop working on it, or whenever you reach some significant (to you) milestone. Right now, the code in the repo hasn't been updated in over a month, so anything you've done since then isn't recorded. Since two of the main purposes of a repo are to a) save an offsite copy of the work in case of an accident (e.g., you have a drive failure, you accidentally delete a file, or make changes that have to be reverted because they didn't work out) and b) keep a record of how the code changes over time, you are basically operating without a repo at all, at least since the middle of November. When you are actively changing your code, you want to commit to your local repo as often as you can, to give a fine-grained record of the changes, and push to the offsite repo at least once at the end of every coding session.
