| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: http://distcc.googlecode.com/svn/trunk@560 01de4be4-8c4a-0410-9132-4925637da917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I renamed the option to path_observation_re. Now by prefixing
INCLUDE_SERVER_ARGS='-d1 --path_observation_re="/usr/.*"'
to say make include-server-maintainer-check, one gets a message each time the
include server finds a path whose realpath name matches the regular expression.
That results in messages like:
WARNING include server: For translation unit 'src/testtmp.c', lookup of file
'bits/stdio_lim.h' resolved to '/usr/include/bits/stdio_lim.h' whose realpath is
'/usr/include/bits/stdio_lim.h'.
To make the interpretation of quoted arguments within INCLUDE_SERVER_ARGS
correct, I added 'eval' to the command that cranks up the include server. I
remembered to put extra quoted quotes inside the parameters that should be
considered a token after the double interpretation that eval implies.
git-svn-id: http://distcc.googlecode.com/svn/trunk@436 01de4be4-8c4a-0410-9132-4925637da917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During compilation of the Linux kernel messages like:
absolute filepath blabla.h was IGNORED (correctness of build may be affected)
are issued. They are wrong. The problem is that -include or -imacro or even
source file names with absolute filepaths trigger a complaint from the caching
mechanism usually used for relative file names.
We correct this problem.
We also substitute fp_map for includepath_map, which is the now preferred term.
REVIEWER: csilvers@google.com
TESTS:
make pump-maintainer-check
make include-server-maintainer-check
git-svn-id: http://distcc.googlecode.com/svn/trunk@397 01de4be4-8c4a-0410-9132-4925637da917
|
| |
|
|
|
|
|
|
|
|
|
| |
(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
git-svn-id: http://distcc.googlecode.com/svn/trunk@387 01de4be4-8c4a-0410-9132-4925637da917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pump-mode.
An occurrence of say
#include "/usr/include/acl.h"
will normally force the include processor to abort (even when this include is
platform-specific and #ifdef'ed away), because there are no guarantees that the
file /usr/include/acl.h exists on the host. With this option, these includes
will be ignored.
A message like:
WARNING include server: absolute filepath '/usr/include/acl.h' was IGNORED (correctness of build may be affected)
will be printed.
The normal message raised when this option is off, the default, has been
modified. It now mentions the option.
An include server manual page is to follow, which explains the consequences in
detail of using this option.
Testing: this makes the samba-2.2.7 benchmark build without hiccups using distcc
pump. Without the change many compilations fail because the include server
bails out and because another unrelated bug in the include server makes it later
dish up with include closures that are too small.
Revievers: csilvers@google.com, fergus@google.com
git-svn-id: http://distcc.googlecode.com/svn/trunk@337 01de4be4-8c4a-0410-9132-4925637da917
|
|
|
git-svn-id: http://distcc.googlecode.com/svn/trunk@3 01de4be4-8c4a-0410-9132-4925637da917
|
