Automake and bitcode files

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Automake and bitcode files

Robert Szewczyk
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