Compile flag order mixup

[NOhs]

I am not sure if this has been an issue so far, but I just noticed that in target.py the compile flags order is scrambled. I think the intent was to get rid of duplicates, but the current implementation could change the order:

clang-build/clang_build/target.py

Line 148 in c5d5c1b

self.compile_flags = list(set(self.compile_flags))

[NOhs]

I think one solution is to not actually remove duplicates. Clang can handle duplicates, as long as the order is correct, this should be fine.

[GPMueller]

However, duplicate flags can make the commands quite unreadable.
Doesn't Python keep the first entry in a list of any item that appears twice? In that case things should be fine as long as the order of appending (e.g. flags from dependencies versus own) is correct.

[NOhs]

I think the issue is that set does not make any guarantees about order. So when the set is created, everything is thrown around. See also:

https://stackoverflow.com/questions/26420945/python-order-of-elements-in-set

[NOhs]

This might also be an issue for veeeery ugly projects where the order of the include folders matter, because that order is also mangled (see line 85):

clang-build/clang_build/target.py

Line 85 in c5d5c1b

self.headers = list(set(self.headers))

[GPMueller]

I believe I had errors when the -std= flag appeared more than once, even if it was the same standard both times.
Currently not sure what else it might have been, but I believe certain flags should not appear multiple times in different positions.

In the case of link flags especially, it is of course important to keep the order. Maybe a self-written function for eliminating duplicates would do best?

[NOhs]

I think we can just switch to dict as discussed here: https://stackoverflow.com/a/7961390/2305545

[NOhs]

I think IF we keep this, we should actually keep the last occurence of a keyword and not the first, otherwise we have the issue again, that if we have the dependency

my_proj   <-   lib   <- lib2

And lib2 defines the same flag as my_proj, but lib defines overriding flags, lib would "win".

[GPMueller]

I agree, the toplevel target flags should override those of its dependencies.

[GPMueller]

If we preserve a specific order of flags etc. in inheritance, this order should be documented.