#12 strip ../.. from shared headers

[Alexander Stohr]

its sub-optimal design when shared central headers to
use relative paths. the attached patch does remove
those coding from the source. instead the ../.. path
should be added to any workspace project that needs it.
(for the second step it does not make sense to provide
a patch since *.dsp files arent good patch targets.)

[Alexander Stohr]

this patch removes relative paths from source files

[Igor Pavlov]

Logged In: YES
user_id=65083

Why it's bad to use ../..
Does GCC suport it?

[Alexander Stohr]

Logged In: YES
user_id=51309

It is bad because you must be always
in the very same relative distance to that
header file in order to make it work.
if you do have a *.c file that only moves
one dir upper or lower for compile,
then you cannot use that header file any more.

propper method for including general headers
is to specify include paths on the compiler command line.

[Igor Pavlov]

Logged In: YES
user_id=65083

But MSVC can compile such headers from any level.
So the question is about GCC.

[Alexander Stohr]

Logged In: YES
user_id=51309

to my best knowledge, GNUC does support ".." and "/" paths.

reason for the patch was the intention to make those files
portable across misc environents by principle.