[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11089: LINK determination
From: |
Stefano Lattarini |
Subject: |
bug#11089: LINK determination |
Date: |
Sun, 25 Mar 2012 17:20:16 +0200 |
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
- bug#11089: LINK determination,
Stefano Lattarini <=