Hi,
I have a project that brings in several conflicting options to
automake/autotools and I'm looking for the best way to resolve the problem:
* I am attempting to emit LLVM bitcode. The configure script helpfully
determines that the OBJEXT for the files in question is .bc
* the Makefile.am files specify per-object compilation flags, that causes
automake to emit rules of the form:
foo_foo.o: foo.c
.... #compile the object etc.
* when running the resulting makefile, there system complains that there is
no rule to build foo_foo.bc
This problem results from automake hardcoding the extension for the
transformed object files: in automake, within the handle_single_transform
subroutine, there is a comment:
# Only use $this_obj_ext in the derived
# source case because in the other case we
# *don't* want $(OBJEXT) to appear here.
($derived_source ? $this_obj_ext : '.o'),
I also note that automake emits a hardcoded rule for .obj extention.
I could see several ways to solve my problem:
* edit automake code itself to the effect of:
($derived_source ? $this_obj_ext : $obj),
that would emit rules of the form:
foo_foo.$(OBJEXT): foo.c
.... #compile the object etc.
but clearly when the patch was introduced commit 081f2d51 back in 2001
there was a good reason to hardcode .o here. Does this reason still exist?
* Follow a mechanism similar to emitting .obj rules to emit .bc rules
* override OBJEXT for bitcode files and pretend that those .bc files should
really be called .o
Any other suggestions?
Best regards,
rob
