The handling of "path" and "fullpath" was inconsistent, resulting in a
lot of missing dependencies regardless if a separate build directory
was in use.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Don't break Makefile.dep generation if run from a separate build
directory.
config/unconfig.h is a bit special; it is kept in the repository for
the benefit of non-configure users. Therefore, don't have "make
spotless" delete it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Clean up some perl warnings, some of which were legitimate (apparently
undef doesn't actually take a list of arguments, a common enough
mistake that it is mentioned in the man page!, and a list of variables
after "my" can be cantankerous), and some of which were nuisance but
were easy enough to clean up.
Maybe this can resolve the problems with very old version of Perl?
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
1. The mkdep.pl program didn't handle excluded dependencies correctly,
causing it to error out due to config/config.h not existing.
2. NMAKE is sensitive to the order suffixes appear in .SUFFIXES,
causing it to try to use the builtin rule .c.exe instead of
.c.obj -> .obj.exe.
3. NMAKE doesn't handle the && operator between commands.
4. The !ifdef jungle around dependency generation was wrong.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make it possible to keep dependency information separate from the
Makefiles, so we don't have to deal with it noisifying the git logs.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Sometimes we really want to use an extended pathname for an include
file, for documentation purposes; e.g. "config/config.h". This makes
alldeps handle that case correctly (and also adds the config/
directory to directories scanned by alldeps).
It is unclear if this will work correctly if there are include files
with the same name in different directories, but we currently do not
have any case like that.
Reported-by: anonymous coward <nasm64developer@users.sf.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Consistently identify dependencies by their path, not by their
basename. This avoids missing indirect dependencies. Furthermore, we
cannot start scanning files until we know the paths of all potential
targets.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make the source code easier to understand and keep track of by
organizing it into subdirectories depending on the function.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
