we've just come across a problem resulting from the recent change to
consolidate all binaries in one folder: if the project contains a file with
a name that already exists somewhere within in RIOT, the build system will at
some point create a second object file with the same name, overwriting the
first one.
Even worse, this problem already exists within RIOT: for example, there exist
two files called uart0.c (one in sys/uart0, the other in
boards/wsn430-common). This emerged probably during the consolidation of the
boards repository.
As I've stated already in the accompanying PR[1], I see two solutions:
1.) enforce naming conventions for files, so that all files are prefixed with
their module name (this could still lead to cases like the one Ludwig has
depicted, but are much more unlikely).
2.) revert the change to have all binaries in one folder, but having instead
something like
$(RIOTBASE)/bin/$(CPU)/
$(PROJDIR)/bin/$(BOARD)/
Where the first directory contains all RIOT binaries and the second only
project specific binaries. While this solution also helps to reduce redundant
compilings, it still call for a consistent naming scheme - but only within RIOT
itself which is much more manageable.
However, I'd vote for the first solution for now, because it's simpler.
we've just come across a problem resulting from the recent change to
consolidate all binaries in one folder: if the project contains a file with
a name that already exists somewhere within in RIOT, the build system will at
some point create a second object file with the same name, overwriting the
first one.
Hi,
have you tried CMake? It works very well with modularization and optional modules.
It automatically creates subfolders in a dedicated build folder so no file name collisions should occur.
2.) revert the change to have all binaries in one folder, but having instead
something like
$(RIOTBASE)/bin/$(CPU)/
$(PROJDIR)/bin/$(BOARD)/
CMake would create files like build/CMakeFiles/RIOT.dir/cpu.dir/arm_common.dir/arm_cpu.o.
interesting this comes up now, I actually have thought about this problem in December and was then surprised, that no problems with naming conflicts had occurred by then. I would like to suggest a third solution:
3.) encode a source files path into the object files name
for example:
core/thread.c --> BINDIR/core_thread.o
sys/uart0/uart0.c --> BINDIR/sys_uart0_uart0.o
PRJDIR/xy/aa/abc.c --> BINDIR/project_xy_aa_abc.o
This way, no conventions for naming files would be needed anywhere, while naming space collitions should be impossible. And the solution would only affect some Makefiles, so the ‘User’-developer would not even need to know much about it. What do you think?
This way, no conventions for naming files would be needed anywhere,
while naming space collitions should be impossible. And the solution
would only affect some Makefiles, so the 'User'-developer would not even
need to know much about it. What do you think?
Why again don't we just use the original folder names?
This way, no conventions for naming files would be needed anywhere,
while naming space collitions should be impossible. And the solution
would only affect some Makefiles, so the 'User'-developer would not even
need to know much about it. What do you think?
Why again don't we just use the original folder names?
Sounds ridiculous? Yeah, but imagine debugging that...
Japp, haven't thought about this (maybe not soo probable) case -> you
win
The drawback I see with keeping the original folder structure in the
BINDIR is, that the folder names are getting even longer. Could this
lead to problems on host platforms (-->WIN)?
The drawback I see with keeping the original folder structure in the
BINDIR is, that the folder names are getting even longer. Could this
lead to problems on host platforms (-->WIN)?
Isn't the full pathname incuding filename limited (vs. pathname without filename)?
Linux has another problem with it's makefiles. They put hundreds of filenames incl. path in the command line of some tools needed for compilation. Depending on base path length, that brakes. There are patches that use xargs to solve the problem but make compilation slower, so they are not in mainline.
I say, let future RIOT developers deal with that problem. Quote me.
The drawback I see with keeping the original folder structure in the
BINDIR is, that the folder names are getting even longer. Could this
lead to problems on host platforms (-->WIN)?
Isn't the full pathname incuding filename limited (vs. pathname
without filename)?
Linux has another problem with it's makefiles. They put hundreds of
filenames incl. path in the command line of some tools needed for
compilation. Depending on base path length, that brakes. There are
patches that use xargs to solve the problem but make compilation
slower, so they are not in mainline.
Ok, when we think this through, we have 3 command-line calls, that will
use the affected path-to-object-file (call it OBJ for now) and archieve
files (call it AF):
1. compiler: gcc ... -o OBJ ...
2. combine: ar ... OBJ1 OBJ2 OBJn
3. linker: gcc ... AF1 AF2 OBJx
For the 1. case, the filename/path length shouldn't matter, since only
one object file is used in that command (in this case a growing number
of include folders is probably more significant...).
For the 2. case the length of the object-file path length could make a
difference, but as archives only contain a limited number of them
(otherwise we should re-think the size of the archives), we can probably
live with it
For the 3. case: same as number 2, I for the current size of RIOT it
should be fine.
I say, let future RIOT developers deal with that problem. Quote me.
So by quoting Kaspar: "[...] let future RIOT developers deal with that
problem", I'd like to vote for Ludwigs proposal to duplicate the RIOT
hierarchy into the BINDIR.
I've updated the corresponding PR [1] according to the result of our
discussion during the meeting yesterday.
The agreement was to go for the simplest solution for now (and the upcoming
release) and implement something more sophisticated later. For now, we'll just
make sure that there are no duplicate filenames for C-Files in RIOT (except
when their paths are mutual exclusive, like boards/foo/driver.c and
boards/bar/driver.c) and put the object files for the project in a separate
folder.
