Your new release is too "clever" -- using constructs that only work in GNU Make, and options that only work with gcc.
How is this an improvement over the previous release, which built and compiled using just about any make and C-compiler?
I'd suggest that you don't implement changes from the gcc team that don't actually improve the quality of the product. Either that, or make sure that they only be enabled if GNU make or GNU C are detected (the configure script already detects if GNU C is being used, so this isn't really rocket science).
The following are non-portable:
@echo '$(COMPILE) -c $<'; \
$(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
@-cp .deps/$(*F).pp .deps/$(*F).P; \
tr ' ' '\012' < .deps/$(*F).pp \
| sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
>> .deps/$(*F).P; \
C Compiler options:
Each of these will blow up a compile that doesn't use GNU make or GNU C. And some people wish to use other versions of make or (more importantly) non-GNU compilers.
Hmm.. I see your point. I integrated the patches to make life easier for the GCC developers who need to roll future fastjar mods into their codebase. I guess I'll roll back the Makefile & configure changes, and leave the code changes. Thanks for your input.
Thanks for your response as well. These sorts of things do happen, which is one of the nice things of having such a forum like this.
Log in to post a comment.