- # we should never specify -I/usr/include on the compiler command line: this
- # is at best useless and at worst breaks compilation on the systems where
- # the system headers are non-ANSI because gcc works around this by storing
- # the ANSI-fied versions of them in its private directory which is searched
- # after all the directories on the cmd line.
- #
- # the situation is a bit more complicated with -I/usr/local/include: again,
- # it shouldn't be specified with gcc which looks there by default anyhow
- # and gives warnings (at least 3.1 does) if it is specified explicitly --
- # but this -I switch *is* needed for the other compilers
- #
- # note that we assume that if we use GNU cc we also use GNU c++ and vice
- # versa, i.e. this won't work (either for --cflags or --cxxflags) if GNU C
- # compiler and non-GNU C++ compiler are used or vice versa -- we'll fix
- # this when/if anybody complains about it
- if test "${includedir}" != "/usr/include" \
- -a "${includedir}" != "/usr/include/c++" \
- -a \( "${GCC}" != "yes" \
- -o "${includedir}" != "/usr/local/include" \) \
- -a \( "${cross_compiling}" != "yes" \
- -o "${includedir}" != "/usr/${target}/include" \) ;
- then
- includes=" -I${includedir}"
+ includes="-I${libdir}/wx/include/${TOOLCHAIN_NAME}"
+
+ # in inplace case we need to also add path to contrib headers -- do it
+ # unconditionally as they might be used and we have no way of knowing if
+ # they really are
+ if test $inplace_flag = yes ; then
+ includes="$includes -I${prefix}/include -I${prefix}/contrib/include"
+ else
+ includes="$includes -I${includedir}/wx-${WX_MAJOR_VERSION_NUMBER}.${WX_MINOR_VERSION_NUMBER}"