To give a little motivation for this PR: on stm32f4discovery boards there are the same pins for the DAC and/or SPI_0. Moving the DAC to other pins is not possible. Moving SPI_0 does not make sense as the onboard accelerometer is also connected to these pins. In #2018 we decided to leave the pin configuration as it is and just throw a warning if an applications needs both features.

Is it possible to detect different kinds of conflicts?

For the stm32f4discovery Board:
SPI0 and DAC0 are in conflict and ADC0 and DAC0 are in conflict, but SPI0 and ADC0 would be fine.

Can I say something like:
FEATURES_CONFLICT += periph_spi periph_dac
FEATURES_CONFLICT += periph_adc periph_dac

Without getting and error for:
FEATURES_REQUIRED += periph_spi periph_adc

@brummer-simon unfortunately no, the conflicting features are just parsed and if two (or more) are present in the required features of the current application the warning will be shown.

Hm, I think this solution is sub-optimal. By just defining conflicts through their features I fear we end up with more false negatives then actual conflicts. The problem is I don't really have a better idea for now.

Fast idea - how about this:
We put the check for possible conflicts on the bottom of the periph_conf.h, there we could be more precise. Maybe something like this?!:

#if SPI_0 && DAC_0
#warning "Possible conflict in peripheral configuration: SPI_0 and DAC_0 use the same pins"
#endif

Basically I agree with you. But regarding your solution, isn't it a problem that by defualt the SPI_0_EN is defined as 1 which sets SPI_0 (same for DAC) which will throw warnings by default? Or otherwise we need to change all peripherals to be disabled by default?

@haukepetersen I hope that such conflicts are the exception.
I agree with @PeterKietzmann concerns here, which could result in a change on all periph_conf.h files for a (probably) small amount of occurrences where conflicts are possible.

I don't know, I'm not sticking on this PR.

Yep, @PeterKietzmann you are right. But the same is true for the feature based solution, right? I guess we have to think about it some more...

right

Ok, I changed the procedure to allow defining groups of conflicting features.
A group is constructed by separating features with :, e.g.:
periph_spi:periph_dac or periph_adc:periph_dac:my_cool_feature

The number of groups is not limited. Groups are separated with a whitespace, e.g.:
periph_spi:periph_dac periph_adc:periph_dac:my_cool_feature
The number of conflicting features is also not limited.

The warning only appears iff all required features are present in a conflict group.

Please add a README.md to the example which explains what the test should / shouldn't do.

(And also a test target in the Makefile would be great so that this can be automated.)

I do like this solution, is @haukepetersen also happy? A README would be nice, sure...

added README.md

Seems like a nice solution. Well done!

I would ACK this

@PeterKietzmann @phiros I removed the test from the Makefile since I have troubles to execute the python script properly when called from the test: target.
And of course rebased to current master.

@phiros may I assign you? I like this feature but as there had been some discussions in the past I would like to pass this PR so someone with more experience in all that makefile stuff and with a stronger opinion on that.

Travis says there are several trailing whitespaces...

@PeterKietzmann I removed the trailing whitespaces.
Beside the need of squahing travis seems to be happy now :)

@phiros, @PeterKietzmann , @BytesGalore, what's the current state?

@OlegHahm it still works as intended, and I still like it to be merged :) .
The test.py works also, but I can't figure out how I could use it in a test target,
e.g. using make BOARD=stm32f4discovery test.
Calling the script from a make target confuses things with environment variables/exports.

@PeterKietzmann should I squash?

I hoped that someone with more knowledge in the make system (e.g. @phiros) would give feedback. But as nobody NACKed this PR for a long time and this is optional more or less an optinal feature I would finally ACK this now. Yes, please squash!

@PeterKietzmann, did you try? If yes and it works, let's go

squashed.

Okay, I'll do it now. ACK and go