When using socket stdio, add option to replay what has been written to
stdout while not connected (`-r`).
The implementation is to simply use the existing log file (which is
implicitly created when the option is used), and read from it until
EOF upon reconnect.
closes#476
Currrently native overrides the object file targets, because it needs
the different include paths to interact with libc and the OS.
This PR simplifies their makefiles to only override the variable
INCLUDES, instead of overriding the targets.
Many modules have subdirectories. Often these subdirectories should only
be included under certain circumstances. Modules that use submodules
currently need to use this pattern:
```make
DIRS = …
all: $(BINDIR)$(MODULE).a
@for i in $(DIRS) ; do $(MAKE) -C $$i ; done ;
include $(RIOTBASE)/Makefile.base
clean::
@for i in $(DIRS) ; do $(MAKE) -C $$i clean ; done ;
```
This PR moves the `all:` and `clean::` boilerplate into `Makefile.base`.
Closes#993.
We do not need to descend into the modules to know what to do on
`make clean BOARD=blub`. We can just invoke `rm -rf bin/blub`.
This PR only keeps the descending into the USEPKGs, since they might
want to delete cached/downloaded/extracted data.
Creating all object files in one directory is bound to produce name
clashes. RIOT developers may take care to use unique file names, but
external packages surely don't.
With this change all the objects of a module (e.g. `shell`) will be
created in `bin/$(BOARD)/$(MODULE)`.
I compared the final linker command before and after the change. The
`.o` files (e.g. `startup.o`, `syscall.o` ...) are included in the same
order. Neglecting the changed path name where the `.o` files reside, the
linker command stays exactly the same.
A major problem could be third party boards, because the location of the
`startup.o` needs to the specified now in
`boards/$(BOARD)/Makefile.include`, e.g.
```Makefile
export UNDEF += $(BINDIR)msp430_common/startup.o
```
The new target names are easier to remember / decipher:
term
term-cachegrind
term-gprof
term-valgrind
all
all-cachegrind
all-gprof
all-valgrind
all-debug
eval-gprof
eval-cachegrind
native modules will never need the dynamic INCLUDES, so we define our
own NATIVEINCLUDES. Due to the current make structure, the only way to
not use INCLUDES is to redefine the build rules.
