On May 18, Russell Cattelan wrote:
> Phil Schwan wrote:
>
> > While hacking files from scratch, I noticed the huge number of
> > dependencies that #includes don't resolve for themselves. Is there
> > some reason for this, or did it just happen over time? Does anyone
> > mind if I apply this patch? It doesn't fix them all, but it gets the
> > ones that I've run into so far.
>
> What does this fix?
It fixes insane scenarios like this, which was previously in dump.h:
# include <sys/uuid.h> /* resolve xfs_dinode and xfs_sb deps */
# include "xfs_inum.h" /* resolve xfs_dinode and xfs_sb deps */
# include "xfs_types.h" /* resolve xfs_attr_sf, xfs_bmap_btree, and
xfs_dir_sf deps */
# include "xfs_buf.h" /* resolve xfs_bmap_btree dep */
# include "xfs_bmap_btree.h" /* resolve xfs_dinode dep */
# include "xfs_dir_sf.h" /* resolve xfs_attr_sf dep */
# include "xfs_attr_sf.h" /* resolve xfs_dinode dep */
# include "xfs_dir2_sf.h" /* resolve xfs_dinode dep */
# include "xfs_dinode.h" /* resolve xfs_sb dep */
# include "xfs_sb.h" /* resolve xfs_mount dep */
# include "ksys/behavior.h" /* resolve xfs_mount dep */
# include "xfs_log.h" /* resolve xfs_trans dep */
# include "xfs_trans.h" /* resolve xfs_mount dep */
# include "xfs_dir.h" /* resolve xfs_mount dep */
#include "xfs_mount.h" /* for xfs_mount_t */
> The rest shouldn't really matter, as long as it doesn't break either
> one of the build paths.
By this do you mean the module and non-module build path, or the
native and non-native build path, or the delalloc and non-delalloc
build path...?
-Phil
|