automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LINK determination


From: Stefano Lattarini
Subject: Re: 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]