| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
<http://code.google.com/p/distcc/issues/detail?id=9>:
use S_ISLNK and S_ISDIR macros, to make the code more readable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gvn --project https://distcc.googlecode.com/svn/trunk review klarlund/d3b3
Fix Issue 7: Compiling with -I/usr/include/FOO or ... in pump mode
Problem:
Default system include directories are the directories on the default include
search path, such as /usr/include, that is determined by the compiler. Distcc
will not send default system include directories to the distcc compilation
servers. Nevertheless, distcc on the server blindly rewrites -I options such
as -I/usr/include/foo to -I/tmp/distccNNN/usr/include/foo.
This doesn't work, since the files in /usr/include/foo are not sent to the
distccd server.
Solution:
The present solution keeps the rewriting on the server, because we would like
to not manage starting the compiler, parsing its output, and storing the
default system paths on the server
Instead, we use the existing mechanism for defining relative symbolic links
under the server root. We escape from the root by using a sufficient number
of '../'s.
All this is tremendously complicated by:
-- The possibility that other links encountered may point into the system
default dirs in which case the usual mirroring of the reachable places
should not take place, because the routing of such links will go through
the link created for the system directory.
-- The fact that determination of default-system-dirness is lazy: a
deeply-seated link in a default system dir may become obsolete if it is
later determined that a higher directory than the parent directory of the
link is in fact also a default system dir. In that case, a new symlink,
sitting in a place higher than the previous one will need to be created.
Tests:
make check
benchmarks: samba (still 3X faster than with distcc), linux 2.6 kernel, and
a couple of others
TODO: better testing
TODO:
> In compiler_defaults.py, _MakeLinkFromMirrorToRealLocation:
> Maybe comment each of the 'if' cases with an example of how this case
> might be triggered. eg the real_prefix == rooted_system_dir is
> triggered when we see /usr/include/foo, and the later see
> /usr/include.
|
| |
|
|
|
|
|
|
| |
(typically the only change is in the FSF street address). Add Google
copyright line in some places it was missing. Add GPLv2 notice to
avahi patches.
OKed by fergus
|
| |
|
|
|
|
|
|
|
| |
Also, fix the emacs var-setting line: it was missing a semicolon
before, which means the entire line was being ignored.
No contentful change.
Reviewed by fergus@google.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lines. Fixed up resulting mis-indented code I noticed (mostly in
files that used 8 space indents, or used 4-space and 8-space indents
in the same file (!)). Added the emacs tab-var setting for all files,
not just some of them.
I also added in copyright notices for files I noticed that didn't have
them. We'll want to do another pass-through to fix these up properly,
though.
I used the following perl snippet to check for mis-indented code after
converting tabs to whitespace:
$ for i in *.{c,h}; do echo $i; perl -nle 'if ($indent > 0) {$sp=" " x $indent; /^$sp[^ ]/ && print "$.: $_"; $indent=0;}; if (/^( *).*{/ ) {$indent=length($1);} else {$indent=0;}' $i; done | less
It had false positives, but hopefully didn't miss anything.
Reviewed by klarlund@google.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
affects the way emacs users will see these files, when visiting them
in emacs. In particular, tabs will show up as 4 spaces, which is
(clearly) the setting the original distcc author used when writing the
code.
We also set an emacs variable to never insert new tabs, but use spaces
instead. This will help stop the problem we have now with mixed tabs
and spaces. In a future cleanup, we may replace all tabs with 4
spaces, and make other whitespace improvements.
The final new variable set, is to set line-wrapping at 78 chars.
Personally, I would have made it more like 72, but some existing files
already had the 78 limit, so I just do that everywhere, to be
consistent.
Reviewed by fergus@google.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tmpdir should not end in a slash -- at least, inside distcc, you see
code like this:
snprintf("%s/%s", tmpdir, filename)
On the other hand, windows's routine to create a tempdir guarantees it
will end with a slash. I'm not sure it really matters, but get rid of
the slash in that case. That way we don't have to worry about how
filenames are interpreted (since // does have a special meaning for
filenames in windows, though probably not in a way this code could
generate before; still, no harm in normalizing to one slash).
Tested by running 'make check' on cygwin.
Reviewed by fergus@google.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(1) Correct order of -Is in Makefile.
(2) remove unnessary PATH modification in configure.ac (this is fergus's
suggestion -- hopefully this will do, this replaces a circumvention mechanism I
had originally concocted.
(3) Fix place of the include of popt in CPPFLAGS.
(4) Convert quoted includes of config.h to angle bracket includes so that the
build version, not the source version, of this file is picked up.
The order of -Is in the build system is wrong: it contradicts the
VPATH mechanism.
This means that builds in a build directory different from that
of the source (distribution) directory will find wrong files even
after the hapless developer has issued only a 'configure' command
in the source directory (but not actually 'made' any thing
there). For in that case, the src/config.h will be generated in
the source directory and this will be the file picked in the
build directory even if that directory has it's own src/config.h.
This can lead to wrong builds and it can be hard to diagnose the
problem.
Currently, this what CPPFLAGS end up being (as found in the
generated Makefile):
CPPFLAGS = -DHAVE_CONFIG_H -D_GNU_SOURCE \
-I../distcc/popt -I../distcc/src \
${DIR_DEFS} \
-Isrc -Ilzo \
-I"$(srcdir)/src" -I"$(srcdir)/lzo" \
Here my source dir was ../distcc.
The presence of '-I../distcc/popt' in front of -Isrc is the exact
opposite of the semantics of VPATH mechanism, which looks for
files in the build directory, then in the source directory.
Also, note the remarks in:
http://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
(they do not quite correctly discuss the search path, btw).
TESTING: I verified that with a corrupted config.h file in the source directory,
building now succeeds.
Also: make distcheck (it fails the same place as before: this is corrected in
another change of mine --- I'll verify that with that change in place, this
change makes 'make distcheck' succeed.)
REVIEWERS: fergus@google.com, csilvers@google.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the unittests to pass, on FreeBSD 6.0, Solaris 10 x86, and OS X
Leopard. You have to use gmake instead of standard bsd make, though,
because neither bsd nor solari make understand 'include */*.d' and
'CFLAGS += $(POPT_FLAGS).' These may be fixable later.
Most changes fall into four categories:
1) #include differences
2) New errors due to some #ifdef paths being taken differently
3) Undefined functions (see, eg, the new HAVE_STRSEP)
4) Type differences (eg tv_usec is an int on os x, not a long int)
As one concrete example, snprintf.c is an empty file on linux, where
all the functionality is part of glibc. But on Solaris, some of its
functionality is useful. This turned up a bug where if you have
vsnprintf on your system but not vasnprintf, then dopr() was not being
used but was being defined, leading to an "unused static function"
warning in gcc.
As another, solaris would complain about "index" being used as a
variable, since it's also a function name. The var was renamed idx.
Tested by compiling on FreeBSD, Solaris 10, and OS X leopard (x86). I
also compiled and ran unittests under Linux Ubuntu, to make sure
this change didn't break anything there.
Reviewed by fergus@google.com
|
|
|
level. I'm doing this in two stages, because I don't understand svn
enough to be confident to do it in one. This first stage just copies
all the files from distcc/FOO to FOO. Now there are two copies of
each file under distcc; the Makefile/etc uses the one in distcc and
ignores the one at the top level.
The next commit will delete everything under distcc, and rewrite the
Makefile/etc to use the top-level versions instead.
|
