Adam C Powell IV <hazel...@debian.org> writes:
> I've put .NOTPARALLEL: in the Makefile.am of that directory and am not
> seeing any problems in three builds (where before it failed every time),
> so I'm pushing this to alioth and marking it pending. Yay!
Sounds good!
> Aaron, do you have any advice on avoiding race conditions in generated
> code? I tried having the omniidl targets include touching a stamp file
> after finishing code generation, but couldn't get that to work.
The problem appears to be that they run the same command:
.idlSK.cc:
$(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $<
.idl.hh:
$(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $<
As such, make inadvertantly clobbers one SK.cc file in the course of
(re)generating the corresponding .hh file for the other source file. :-/
If my analysis is correct, you can work around the bug by having the .hh
file claim to depend on the SK.cc file:
%.hh: %SK.cc
%SK.cc: %.idl
$(OMNIORB_IDL) $(IDLCXXFLAGS) $(OMNIORB_IDLCXXFLAGS) $<
(The .idl -> SK.cc rule could continue to use the traditional syntax,
but I consider modern %-style pattern rules a better choice for two
reasons:
- The somewhat artificial SK.cc -> .hh rule would otherwise need a dummy
command.
- They are clearer, particularly in the face of suffixes not starting
with dots.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
