Re: LINK determination

[Jason DeVinney]

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
<address@hidden> 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