Stefano, Thanks for the reply. I am satisfied with this. I just wanted to make sure I wasn't missing something.
Cheers, Jason On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini <stefano.lattar...@gmail.com> wrote: > Severity: minor > > [CC:ing bug-automake, so that we won't forget about the issue] > > On 03/23/2012 03:32 AM, Jason DeVinney wrote: >> Hi all, >> > Hi Jason, sorry for the delay. > >> I have a upc program with *.upc source files. I have some macros that >> make UPC code look effectively like C code and so it is easy to >> compile this program as a C program as well. My Makefile.am has the >> following lines >> >> bin_PROGRAMS = foo >> common_sources = file1.upc file2.upc >> >> if BUILD_UPC >> foo_LINK = $(UPCLINK) >> foo_SOURCES = $(common_sources) >> else >> foo_LINK = $(LINK) >> foo_SOURCES = $(common_sources:.upc=_c.c) >> fi >> >> I also have some code in my Makefile.am to tell make how to create >> (with links) the file1_c.c and file2_c.c files. The BUILD_UPC variable >> is set with AC_SUBST in my configure.ac based on a configure option >> (--disable-upc). If no option is given then BUILD_UPC is set to 1, but >> if --disable-upc is given BUILD_UPC is zero. automake is correctly >> automatically determining which compiler to use in both cases, but for >> some reason it wants to use the UPCLINK linker in both cases. I read >> section 8.13.3.1 How the Linker is Chosen, in the automake >> documentation and it says that automake determines which linker to use >> based on the foo_SOURCES variable, so I can't see why I need to >> include the two foo_LINK lines in my Makefile.am (I would like to >> avoid this). Does anyone know why this is happening? Am I forgetting >> something? >> > I'd describe this as an automake limitation; not sure if it's worth > fixing (since yours is not a common use case, and the issue you're > facing has a simple-enough workaround, as you've already found out); > but it would be worth documenting IMHO. Care to write a patch? > Otherwise, I'll try to cook one up myself before the 1.11.4 release > (but I'm short of time these days, so no promise). > > Thanks, > Stefano
