Discussion:
Automake and bitcode files
Robert Szewczyk
2015-10-21 23:39:37 UTC
Permalink
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

Loading...