The concept of headers in C was necessary at its time, but these days it just makes compilation of complex program in complex environment several times more complex. Whenever you have several package-roots (I have /usr, /usr/local, /sw, /opt/local, /opt/some_pkg1, /opt/some_pkg2 at the same time), which have different versions of the same libraries, you need to separately check resolution order of libraries and header-files.

Sometimes it feels completely counter-intuitive and you just end up manually hiding some files.

Common end-user solution is just sticking to the package-root provided by distribution (usually “/usr”), but that is not an option for developer, who needs to test different combinations of bleeding-edge apps.

How do you manage this stuff?

Example. I need to build php6 (installation prefix /opt/php6) with:

• iconv from /sw (whle there is other iconv in /usr)

• libxml from /usr (while there is other libxml in /sw)

• icu from /sw/local (while there are pieces of other icu’s in /sw and /usr)

In reality, there are more libs involved, and complexity arises, when these different libs are needed by the same components of php. I start thinking, that I should create some special package-root and just symlink every needed library in it. And just give it as the only package-root to php. Seems like a complex task, while considering all dependencies.

In my ideal world, there would be no name-resolution at all, compiler would just require exact position of library (which would be represented by the single file)