Closed KaelenHaag1 closed 4 years ago
Sounds like a good idea.
This is generally a good idea, although people try to not mix things that are unrelated into a single header file (coherence). Usually what you do is to separate concerns and create a variety of header files in an include directory and include only what is really needed. Bool, e.g., would deserve to get its own header file. That said, there is typically still one header in it with commonly used things like internal constants that really don't belong anywhere else :-)
Also, we possibly need a set of headers for the kernel and a different set of headers for the userspace since both parts are neither going to be really part of the same build process (they don't link against each other), nor should the user space be exposed to kernel internals.
I think we should also do the same for drivers (e.g. DMA, clock) and for lib stuff (libc, data structures, etc.). Of course, it doesn't matter until we actually have some code, but it'd be good to have some structural collections in place.
+1
I've added a preliminary global defs header file and modified the Makefile so that it should search the include directory automatically. Let me know if anything looks off.
Would it be a good idea to throw up a "build" directory as well, just to consolidate everything from the make process?
since the makefile is now remade to make all headers accessible globally, this does not seem necessary anymore.
Would it be a good idea to have like a global definitions header file where we would add some widely used definitions like boolean, String, etc.? That way it would force some consistency in the project.