Il 16/09/2012 16:40, Anthony Liguori ha scritto: > It's good to put includes in a single direction such that you can do > -Iinclude and then: > > #include "qemu/foo.h" > > Which is better than: > > #include "foo.h" > > Because the later can create confusion/conflict with system headers > whereas the former is (hopefully) completely unambiguous.
My plan for this is to only put directories in include/, which limits a lot the possibility of confusion, for example #include <exec/cpu-all.h> #include <qapi/qapi-types.h> etc. Unfortunately, this _does_ require touching every .c file. >> > Moving to include/ would be to clean up the top-level directory, withour >> > touching the source code. If something can be moved directly to one of >> > the new source directories, that's also fine but I don't have high >> > hopes. > I actually thinking moving to -Iinclude is a Good Thing for now because > it avoids touching a bunch of .c files. In the longer term, we should > continue to clean up headers and move them into qemu/ though. I disagree about qemu/ vs. other directories, but yes, it is better to avoid touching .c files at the same time you're moving them. It is not completely possible, mostly because some header files in net/ combine both private content (which should move to sysemu/net/) and public content (which should move to include/net/), but that should be the exception. Paolo
