#190 can break rust_icu_sys build

The recent pull request #190 breaks the build of rust_icu_sys on my Fedora 33 machine.

On my computer, pkg-config --cflags icu-i18n prints out a blank line, because the only include directory is the default system search path /usr/include.

This causes a problem here:

rust_icu/rust_icu_sys/build.rs

Line 267 in 2d5cfd8

for include_dir in include_dirs.iter() {

The loop doesn't execute, so only f is passed to the next stage of the expression, resulting in lines that look like:

#include "ubrk"

which causes bindgen to fail.

It looks like this could be avoided by passing --keep-system-cflags to pkg-config. I don't know how portable that is?

Thanks for the bug report.

I'm not quite sure what is the correct action if the cflags end up being empty. --keep-system-cflags looks like it gets us the needed behavior, but I'd be more interested in a more robust way of getting to the same information. Perhaps a better way forward would be to pass the include directories into bindgen and keep the #include statements relative to the current -I path?

I certainly don't have a good understanding of the different pieces here, but I agree that it would be nice if one could make it so that the #include statements only needed relative paths and there was no need to parse out -I flags and whatnot. The latter seems like it's always going to be a bit fragile.

Turns out it was possible to use only the relative path to the includes, at least according to the CI builds that we have defined at the moment. This gets us out of the business of caring about the exact directory that the include file is located in, and we get to use the relative path only. Please see PR #192. This makes build.rs simpler and likely more robust.