When I started using this IDE I was a little dissapointed, since it ignored #pragma comment() directives for linking libraries.
However that was one thing I was ready to forgive untill I came up with this:
Creating a WIN32 application you end up with Win95 style(stuff works, but looks old..), so in VS all I had to do was add this at the begining:
The behavior of #pragma is implementation-defined (either that or just undefined. I can't remember ATM). There's no point in expecting that two different compilers will respond to the same #pragma the same way.
You probably can do in MinGW most of that fluff you passed to the linker, but you'll have to do it with command line options (Code::Blocks has a configuration dialog for that).
Is there not a Windows XP Look and Feel option on your Plugins menu??
There is on my codeblocks version ( 10.5).
This will put a manifest file in the Release directory - it doesn't seem to work for Debug - but I just copied the manifest file from the Release directory to the Debug directory.
Now you're even suggesting putting those in library headers? Show me the guy who'll appreciate that. You usually don't want to link to a library every single time you compile something that #includes a header from it.
It's only easier when the user has a compiler that understands that pragma and a linker that understands those options. If they dare use a different toolchain than you, then chances are good it won't work as intended (if at all) and might even make things more complicated.
If you want to make things easier for users, use something like CMake. At least that behaves the same with every compiler/platform it supports.
So, Boost has a program that automatically writes those pragmas to their header files? Also, on Linux you wouldn't have to have pragmas or manually link to any libraries, since you can just put `pkg-config --libs $library` in your LDFLAGS.
You usually don't want to link to a library every single time you compile something that #includes a header from it.
Um... yeah you do. If you are using anything in the header, you'll have to link to the library or you'll get linker errors. And if you aren't using anything that requires linking the library, you probably shouldn't be including the header.
The two go hand in hand.
If they dare use a different toolchain than you, then chances are good it won't work as intended (if at all) and might even make things more complicated.
Right. It only works for a specific toolchain. However putting it there doesn't cause anything to fail if people aren't using that toolchain.
Why not put it there for where it's supported to make it easier for some people? For those people using a different toolchain, they can link the libraries the usual way.