On 04.09.2013 03:41, Gabriel Dos Reis wrote:
On Tue, Sep 3, 2013 at 9:33 PM, Mike Stump <mikest...@comcast.net>
wrote:
On Jul 12, 2013, at 11:18 PM, Adam Butcher <a...@jessamine.co.uk>
wrote:
* gcc/cp/semantics.c (build_lambda_expr),
(build_lambda_object), (begin_lambda_type),
(lambda_return_type),
(lambda_function), (lambda_capture_field_type),
(is_capture_proxy),
(is_normal_capture_proxy), (insert_capture_proxy),
(insert_pending_capture_proxies), (lambda_proxy_type),
(build_capture_proxy), (vla_capture_type),
(register_capture_members), (add_default_capture),
(lambda_expr_this_capture), (maybe_resolve_dummy),
(nonlambda_method_basetype), (maybe_add_lambda_conv_op) and
(is_lambda_ignored_entity): Moved definitions into ...
* gcc/cp/lambda.c: ... this new file.
This can cause an incremental build failure because there are no
dependencies:
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 2c1774f..65dfe08 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -351,6 +351,7 @@ cp/vtable-class-hierarchy.o:
cp/vtable-class-hierarchy.c \
cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H)
coretypes.h \
$(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h
$(PARAMS_H) \
$(DIAGNOSTIC_CORE_H) $(FLAGS_H) debug.h pointer-set.h
+cp/lambda.o: cp/lambda.c $(CXX_TREE_H) $(CGRAPH_H) $(VEC_H)
$(SYSTEM_H) coretypes.h
cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H)
\
$(CONFIG_H) $(SYSTEM_H) $(TM_H) coretypes.h $(CXX_TREE_H)
tree-pretty-print.h
When tree codes are added or moved, the check is then against the
wrong number, and this will kill the build.
I'm still looking forward to the day when all the dependancies are
unceremoniously ripped out, until then...
Ok?
OK.
Eek. I didn't realize dependencies had to be manually specified.
That's prompted me to update a more recent patchset I'm working on where
I've introduced a new header.
Is anyone working on using some use, perhaps filtered, of -MD (or -MDD)
to generate deps on the fly? I haven't looked into the GCC makefile
system in any detail but I assume dependency handling is more complex
than the standard usage pattern for -MD or I guess someone would have
done it already. Or are maintainers worried that auto deps will slow
the build down too much? In our team's experience with using -MD the
overhead is negligible; especially when weighed up against the effort
required to manually maintain deps. It just takes make a little longer
to start actually building anything.