On Mon, 7 Mar 2005, Zack Weinberg wrote:
> I would take this approach if there were a sensible way to deal with
> the generated sources.
(Late in the game here, but I see no solution in later posts in
this thread.)
All #includes that can appear are in the gen* files IIUC.
Can those be marked up,
Tom Tromey <[EMAIL PROTECTED]> writes:
> > "Zack" == Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> >> Computed headers are dealt with somewhat clumsily in automake. As a
> >> user you specify "BUILT_SOURCES", and then these are built by 'all'
> >> before anything else is done.
>
> Zack> Thi
> "Zack" == Zack Weinberg <[EMAIL PROTECTED]> writes:
>> Computed headers are dealt with somewhat clumsily in automake. As a
>> user you specify "BUILT_SOURCES", and then these are built by 'all'
>> before anything else is done.
Zack> This might not be all that bad in gcc land. It's good to
On Tue, 2005-03-08 at 17:25 +, Paul Brook wrote:
> > (a) the numbers reported by the "time" command,
>
> real3m52.604s
> user3m15.490s
> sys 0m29.550s
>
> > (b) what sort of machine this is and how old
>
> hp-pa 712/80. At least 7 years only, probably more. This machine takes man
> (a) the numbers reported by the "time" command,
real3m52.604s
user3m15.490s
sys 0m29.550s
> (b) what sort of machine this is and how old
hp-pa 712/80. At least 7 years only, probably more. This machine takes many
hours to bootstrap gcc.
> (c) whether or not you would be willing t
On Mar 8, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> I wouldn't. automake has a much better solution for this that doesn't
>> introduce any such delays.
> Well, yes, but tell me how to make it play nice with all our generated
> header files.
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 7, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
>
>> (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependencies manually anymore.
>
> I wouldn't. auto
On Mar 7, 2005, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> (c) whether or not you would be willing to trade that much
> additional delay in an edit-compile-debug cycle for not having to
> write dependencies manually anymore.
I wouldn't. automake has a much better solution for this that doesn't
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Maybe cpplib could even be hacked to have a mode where (when
> generating dependencies) it silently permits #include of an
> non-existing file, considers it a dependency in the current
> directory, and just keeps going? I have insufficient cpplib taste
Tom Tromey <[EMAIL PROTECTED]> writes:
> Automake also doesn't do a separate "make depend" step. Dependencies
> are computed as a side effect of compilation.
I would take this approach if there were a sensible way to deal with
the generated sources.
> Computed headers are dealt with somewhat cl
Daniel Jacobowitz wrote:
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote:
We do need a story for generated headers. I'd be happy with explicit
dependencies in the Makefiles indicating what source files depend on
what generated headers. We'd still be able to get rid of 99% of the
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote:
> We do need a story for generated headers. I'd be happy with explicit
> dependencies in the Makefiles indicating what source files depend on
> what generated headers. We'd still be able to get rid of 99% of the
> dependencies in o
I don't think this has to be perfect to be a big win over what we've got.
The worst slowdown anybody is reporting with Zack's simple-minded
approach is on the order of a minute. That's on slow machines, where a
GCC bootstrap will take hours. So, I'm not worried about the time *at
all*. I'd be
(a)
real0m5.171s
user0m4.346s
sys 0m0.518s
(b)
Athlon64 3000+ (2.0 GHz s754), 1GB RAM, 200 GB disk, SuSE Linux 9.2
8 month old. Today's Paris street price about 500 euros w/o taxes
(c)
automatic seems better
Laurent
On Mon, 2005-03-07 at 00:07 -0800, Zack Weinberg wrote:
> I'd appr
> "DJ" == DJ Delorie <[EMAIL PROTECTED]> writes:
>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
DJ> The problem with .d fil
Zack Weinberg <[EMAIL PROTECTED]> writes:
> It is from 2x to 7x faster, depending on whether the filesystem cache
> is primed. There doesn't seem to be any way to get it to read
> multiple include directories, so the results are not entirely
> accurate, but that's a fixable problem.
^^ I meant to
DJ Delorie <[EMAIL PROTECTED]> writes:
>> That script doesn't really parse the file at all, it just scans for
>> #include lines, and it processes each header only once no matter how
>> many files reference it. Which has got to be faster than what
>> cpplib is doing.
>
> Right, I figured you could
> That script doesn't really parse the file at all, it just scans for
> #include lines, and it processes each header only once no matter how
> many files reference it. Which has got to be faster than what
> cpplib is doing.
Right, I figured you could run it once just to see how *much* faster
it
DJ Delorie <[EMAIL PROTECTED]> writes:
>> probably the sanest thing is to go with the automake-like approach of
>> one .d file per .c file, which then can be annotated without having to
>> write logic to parse a big dependency file and update it in place.
>
> The problem with .d files is that ther
> probably the sanest thing is to go with the automake-like approach of
> one .d file per .c file, which then can be annotated without having to
> write logic to parse a big dependency file and update it in place.
The problem with .d files is that there's no good automatic way to
deal with header
DJ Delorie <[EMAIL PROTECTED]> writes:
>> and (c) whether or not you would be willing to trade that much
>> additional delay in an edit-compile-debug cycle for not having to
>> write dependencies manually anymore.
>
> Are there any compromise solutions?
Lots.
The program as it currently exists i
> > Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
>
> Lucky guy! ;)
Oops, I mean 2GHz :-P
(I have another new machine that's a P4 3GHz)
DJ Delorie wrote:
> Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
Lucky guy! ;)
Paolo.
> (a) the numbers reported by the "time" command,
> (b) what sort of machine this is and how old,
Thinkpad 600 (RHL 9 i386, PII 266MHz) 192Mb (7 yrs old)
real0m46.115s
user0m40.080s
sys 0m3.930s
Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
real0m4.344s
user0m3.875s
sys
On Mon, Mar 07, 2005 at 12:07:30AM -0800, Zack Weinberg wrote:
> ... report (a) the numbers reported by the "time" command,
real1m25.959s
user0m6.070s
sys 0m2.820s
(b) what
> sort of machine this is and how old,
dual 2.175 GHz Xeon with 2GB memory, about three years old
> and (c)
[EMAIL PROTECTED]: 12.154user 1.073system 0m15.372selapsed 86.05%CPU
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely
On Mon, 07 Mar 2005 00:07:30 -0800, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> (a) the numbers reported by the "time" command,
real0m15.369s
user0m7.305s
sys 0m1.033s
(source over NFS)
> (b) what sort of machine this is and how old, and
4xItanium2 1.3GHz, Debian unstable. Two ye
(a) the numbers reported by the "time" command
real0m49.88s
user0m11.57s
sys 0m3.77s
(b) what sort of machine this is and how old
IBM pseries POWER4 1.1GHz, AIX 5.2.0.0
David
Zack Weinberg wrote:
>
> and report (a) the numbers reported by the "time" command,
real0m7.819s
user0m4.442s
sys 0m0.513s
> (b) what sort of machine this is and how old, and
x86_64-unknown-linux-gnu, AMD Athlon(tm) 64 Processor 3700+
> (c) whether or not you would be willing to
Zack Weinberg wrote:
(a) the numbers reported by the "time" command,
real0m10.129s
user0m4.387s
sys 0m0.726s
(b) what sort of machine this is and how old, and
i686-pc-linux-gnu, P4 3GHz (about a year old).
(c) whether or not you would be willing to trade that much additional
delay in an
real0m18.740s
user0m0.010s
sys 0m0.020s
i686-pc-mingw32
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
1.4GHz Pentium 4 768MB RAM
I have no preference regarding makedepend.
Aaron W. LaFramboise
and report (a) the numbers reported by the "time" command, (b) what
sort of machine this is and how old, and (c) whether or not you would
be willing to trade that much additional delay in an edit-compile-debug
cycle for not having to write dependencies manually anymore.
Linux P4 3.4 GHz: real0
I'd appreciate it if y'all would do the following sequence of commands
on your favorite machine:
srcdir=/path/to/gcc/source/tree/
$srcdir/configure
make all-libcpp configure-gcc
cd gcc
make config.h tm.h
time ../libcpp/makedepend -I. -I$srcdir/gcc -I$srcdir/libcpp/include \
-I$srcdir/include
33 matches
Mail list logo
