[riot-devel] Naming of source files

Hauke Petersen hauke.petersen at fu-berlin.de
Mon Jan 13 09:53:23 CET 2014

Hej everyone,

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?


On 10.01.2014 18:52, Oleg Hahm wrote:
> Dear rioters,
> 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.
> Anyone with a better solution?
> Cheers,
> Oleg
> [1] https://github.com/RIOT-OS/RIOT/pull/494
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140113/5ef1d7c5/attachment.html>

More information about the devel mailing list