Too many flags in opensaml pkgconfig

[Cantor, Scott]

> I see that this is generated from a macro that came from the Autoconf
> archive, but I think it's not really correct.  I'm fairly sure that its
> inclusion of @CFLAGS@ in Cflags is wrong (those optimization flags aren't
> required for clients of the library), and its inclusion of @LDFLAGS@ in
> Libs is probably also wrong.

If you split LDFLAGS and LIBS, then how do you get any other relevant LDFLAGS into the build when the only option pkg-config has is --libs?

The more important point though is the CFLAGS one. On some platforms, you need the right options to be in place consistently across the build to ensure thread safety. Just defining the right include path won't ensure a safe result. Solaris in particular.

Admittedly there are other things in CFLAGS, but the macro didn't really give me a lot of control. I don't use the pkg-config tool so it's possible I erred by bothering to include it as a toss-in.

> anyway, and the -L${libdir} and -I{includedir} will of course always take
> care of finding OpenSAML's own libraries and headers.  Which I think is
> all that you, as library provider, are really responsible for.

I felt like the only value would be if the tool made it more likely to get a safe outcome and allowed for a one-step query to get all the flags for that layer and all the lower layers. Just handling -I and -L is fairly limited.

> The only thing I'm not sure about is if -pthread is required for all
> clients of the libsaml library (mostly because I've never been completely
> clear on when that flag is required).

Generally flags involving threading cause a lot of internal things to happen to get thread safe versions of library functions and proper startup/shutdown code. On Solaris at least, it's essential.
 
-- Scott