[Top][All Lists]

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

subdir-objects generates subdirs with unsubstituted variable names

From: R. Diez
Subject: subdir-objects generates subdirs with unsubstituted variable names
Date: Mon, 6 Oct 2014 20:23:36 +0100

Hi there:

I have the following open-source project that cross-compiles to an embedded 

I am trying to keep automake happy in order to prevent the following kind of 

  EmptyFirmware/ warning: source file 
'$(CMSIS_SRC_TEMPLATE_DIR)/system_sam3x.c' is in a subdirectory,
  EmptyFirmware/ but option 'subdir-objects' is disabled

After all, as far as I am concerned, automake can create as many subdirectories 
as it wants in the build directory. However, when I add option 
"subdir-objects", automate generates subdirectories like this when compiling:

drwxrwxr-x 3 rdiez rdiez  4,096 Oct  6 20:53 $(BARE_METAL_SUPPORT_DIR)
-rw-rw-r-- 1 rdiez rdiez 30,584 Oct  6 20:53 Makefile

Note that the directory name contains a GNU Make variable that has not been 
substituted. Later on, linking fails because it does substitute properly when 
looking for the file. For example:

 No such file or directory

I looked further around the in build directory, and I found more directories 
like that:

  $ find . -name "\$*"

Note that the $(ASF_BASEDIR) etc. variables have not been expanded either when 
creating those directories. Those variables do work well all over the place, as 
I am using "AC_SUBST(ASF_BASEDIR)" and so on in the top-level 
file. I guess autoconf or automake are not dealing correctly with those 
absolute paths outside the project directory when they contain variables.

I am using Ubuntu 14.04, which comes with autoconf 2.69 and automake 1.14.1. I 
am building out of the source tree.

I could try with VPATH, but then there will be ambiguities if 2 files are 
called the same but live in different subdirectories in the source tree.

The Atmel Software Framework (ASF) is a C source code library that, as far as I 
know, does not provide an autotool building environment. My project does use 
the autotools. Some C++ source files are in my project's directories, but some 
files live in the ASF directory, which can be anywhere on the system (user 
configurable, normally an absolute path).

I thought I could just reference those ASF .c files from my autotools project, 
but with the latest versions I am getting warnings like the ones above. This is 
how I am referencing the files:

libsam_a_SOURCES = \
     $(LIBSAM_PMC_DIR)/pmc.c \
     $(LIBSAM_PMC_DIR)/sleep.c \
     $(LIBSAM_PIO_DIR)/pio.c \
     $(ASF_BASEDIR)/sam/drivers/wdt/wdt.c \
     $(ASF_BASEDIR)/sam/drivers/rstc/rstc.c \
     $(ASF_BASEDIR)/sam/drivers/uart/uart.c \
     $(ASF_BASEDIR)/common/utils/interrupt/interrupt_sam_nvic.c \

I wonder if that is the right way to reference those files. Maybe I should 
create a library for each foreign directory referenced that way.

This kind of question has been asked before, but I have not found a 
satisfactory answer yet. For example:
  "Source files in different directory?"

Here too:

Think, for example, of sources being in a read-only mount (like a CD-ROM).

Other files do live in my project directory, but are special and get referenced 
directly from the main makefile:

# See the comments in the Bare Metal Support library's
# for information about why these files are compiled here.
emptydue_elf_SOURCES += $(BARE_METAL_SUPPORT_DIR)/NewlibSyscalls.cpp
emptydue_elf_SOURCES += $(BARE_METAL_SUPPORT_DIR)/crt0.cpp

Is this a bug in automake? Or is there a way to keep Automake happy?

Please copy me on any answers, as I am not subscribed to this list.

Thanks in advance,

reply via email to

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