Page 2 of 2

Re: Makefile issues

Posted: Wed Oct 30, 2013 12:27 pm
by iggarpe
I can't see any viable solution for paths outside the user project directory, that includes the case where the user project is actually inside ChibiOS/RT source tree, though not my case (it's in ../ChibiOS-RT261).

Problem is that for a static rule to match the object file and the source file paths must coincide, except for prefixes. This applies to your suggestion of unique names for object files, besides it would not be trivial to make those names not only unique but fixed for each source (otherwise the object would be recreated on each compile).

There's a possible solution but it's ugly as hell: generate a per source file makefile to be included, kind of how it's done for dependencies. That way you can arbitrarity link any object file to any source file.

There are though a couple of paliative measures I would implement for the next release:

1- Rename "shell" to "chshell" or something like that. "shell" is a filename too likely to cause conflicts. See if there are other files that would be advisable to rename.

2- Remove the sorting from SRCPATHS assignment. As far as I can see it serves no purpose, whereas removing it gives the user a chance to order his CSRC sources in order to give precedence to his own files over ChibiOS/RT files in case of conflict (all $(CHIBIOS)/whatever sources should be at the end of the CSRC assignment in the user's Makefile). Also it would be a good idea to add a comment in the template makefiles describing the potential problem and advising to place all ChibiOS/RT sources at the end of the CSRC assignment.

Re: Makefile issues

Posted: Wed Oct 30, 2013 1:04 pm
by iggarpe
Symlinks?

Two approaches:

a) Have the makefile create in build/lnk/ symlinks to all the source files, then use those symlinks as the actual source prerequisites.

PROBLEM: what about filesystems that don't support symbolic links?

b) Forbid to use sources outside of your project's directory, by either warning that it may wreak havoc or having the Makefile issue an error message.

The modify the Makefile as I described in a previous message so that the source tree is replicated into the build/obj/ directory.

The user would be responsible for creating symbolic links into his project to other source folders, mostly to ChibiOS/RT sources.

PROBLEM: again, what with filesystems that don't support symbolic links?.

Re: Makefile issues

Posted: Wed Oct 30, 2013 1:58 pm
by Giovanni
The most feasible suggestion is to work on file names to make them more unique: chshell.c, haladc.c etc. This could be done in 3.0. Introducing a collision check is also possible.

Putting different restrictions in order to avoid a restriction does not sound like a solution.

Giovanni

Re: Makefile issues

Posted: Fri Nov 01, 2013 9:35 pm
by iggarpe
Totally agree. The most practical and quick fix is to prevent name collision by renaming certain ChibiOS/RT files.

My suggestion to "forbid" using sources outside one's project is not actually a restriction, more of an obligation to use symbolic links in order for the make system to work properly. But yes, anyway I don't like that solution either.

I'll give it a bit more though just in case, but I doubt I could come up with a good solution if you haven't already.

Thanks.

Re: Makefile issues

Posted: Wed Nov 06, 2013 8:41 am
by inmarket
From my Win32 Makefile adjusted to solve this naming file conflict problem....

Code: Select all

# Output directory and files
ifeq ($(BUILDDIR),)
  BUILDDIR = .build
endif
ifeq ($(BUILDDIR),.)
  BUILDDIR = .build
endif

OBJDIR    = $(BUILDDIR)/obj
LSTDIR    = $(BUILDDIR)/lst
MAPDIR    = $(BUILDDIR)/map

INCDIR  = $(patsubst %,-I%,$(DINCDIR) $(UINCDIR))
LIBDIR  = $(patsubst %,-L%,$(DLIBDIR) $(ULIBDIR))
DEFS    = $(DDEFS) $(UDEFS)
ADEFS   = $(DADEFS) $(UADEFS)
COBJ   = $(addprefix $(OBJDIR)/, $(SRC:.c=.o))
AOBJ   = $(addprefix $(OBJDIR)/, $(ASRC:.s=.o))
OBJS    = $(AOBJ) $(COBJ)
LIBS    = $(DLIBS) $(ULIBS)

LDFLAGS = -Wl,-Map=$(MAPDIR)/$(PROJECT).map,--cref,--no-warn-mismatch $(LIBDIR)
CPFLAGS = $(OPT) -Wall -Wextra -Wstrict-prototypes -fverbose-asm -Wa,-alms=$(LSTDIR)/$(<:.c=.lst) $(DEFS)

# Generate dependency information
CPFLAGS += -MD -MP -MF .dep/$(@F).d

#
# makefile rules
#

all: $(BUILDDIR) $(OBJS) $(BUILDDIR)/$(PROJECT).exe MAKE_ALL_RULE_HOOK

MAKE_ALL_RULE_HOOK:

$(BUILDDIR) $(OBJDIR) $(LSTDIR):
   mkdir -p $(OBJDIR)
   mkdir -p $(LSTDIR)
   mkdir -p $(MAPDIR)
ifneq ($(USE_VERBOSE_COMPILE),yes)
   @echo Compiler Options - $(CC) -c $(CPFLAGS) -I. $(INCDIR) main.c -o $(OBJDIR)/main.o
   @echo
endif

$(OBJDIR)/%.o : %.c
   @mkdir -p $(dir $@)
ifeq ($(USE_VERBOSE_COMPILE),yes)
   @echo
   $(CC) -c $(CPFLAGS) -I. $(INCDIR) $< -o $@
else
   @echo Compiling $<
   @$(CC) -c $(CPFLAGS) -I. $(INCDIR) $< -o $@
endif

$(OBJDIR)/%.o : %.s
   @mkdir -p $(dir $@)
ifeq ($(USE_VERBOSE_COMPILE),yes)
   @echo
   $(AS) -c $(ASFLAGS) -I. $(INCDIR) $< -o $@
else
   @echo Compiling $<
   @$(AS) -c $(ASFLAGS) -I. $(INCDIR) $< -o $@
endif

%.exe: $(OBJS)
ifeq ($(USE_VERBOSE_COMPILE),yes)
   @echo
   $(CC) $(OBJS) $(LDFLAGS) $(LIBS) -o $@
else
   @echo Linking $@
   @$(CC) $(OBJS) $(LDFLAGS) $(LIBS) -o $@
endif

gcov:
   -mkdir gcov
   $(COV) -u $(subst /,\,$(SRC))
   -mv *.gcov ./gcov

clean:
   -rm -fR .build
   -rm -fR .dep

#
# Include the dependency files, should be the last of the makefile
#
-include $(shell mkdir .dep 2>/dev/null) $(wildcard .dep/*)

Re: Makefile issues

Posted: Wed Nov 06, 2013 3:06 pm
by Giovanni
Hi,

How it is done exactly? do you recreate a subtree or what?

Giovanni

Re: Makefile issues

Posted: Wed Nov 06, 2013 9:43 pm
by inmarket
Yes it recreates a sub-tree.

For some reason it doesn't seem to have issues with ../ in the path.
From my project directory I reference the ChibiOS path as ../chibios

Re: Makefile issues

Posted: Wed Nov 06, 2013 9:50 pm
by inmarket
Ahhh. I had a look at why it had no problems with the ../

Because I am creating the object files in the .build/.obj directory, a single level of ../ moves the ChibiOS directory into the .build directory. Everything is still contained nicely out of site and there are still no naming conflicts so that works for me (even if not all that was originally intended).

So the solution provided works for a single level of ../ in the source file path.