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)
