From: John Maddock (john_at_[hidden])
Date: 2005-06-13 04:43:15
> Maybe this gcc option could be useful?
>
> `-print-file-name=LIBRARY'
> Print the full absolute name of the library file LIBRARY that
> would be used when linking--and don't do anything else. With this
> option, GCC does not compile or link anything; it just prints the
> file name.
No sorry: as the build system works at present, any configuration has to be
done within the jam language, using rules that don't execute any commands!
If I could execute commands to do the configuration this would be easy :-)
But whatever, I've committed a fix that I believe solves the main issues:
certainly std paths shouldn't be added to the include or library search
paths any more (by std paths I mean /usr/include and /usr/local/include),
it's still technically possible for this to do the wrong thing (if a path
other than /usr or /usr/local is a std install prefix), but IMO it's very
unlikely now.
I've also changed the behavior when the ICU lib files aren't found under
$(ICU_PATH)/lib: then it prints a warning, but still adds the "usual"
library names to the linker command line in the hope that they'll be found
in a std path somewhere. Note however that ICU doesn't really have a
consistent naming convention for it's libs: they change quite radically
depending upon the platform, so this probably only works on Linux, and maybe
one or two other Unixes.
Finally, note that I've just corrected a couple of minor bugs in the ICU
support code, so you may want to do a cvs update for these alone (one for
the regex-iterators, plus one very obscure bug for "ignorable" collating
elements).
HTH,
John.