Poco

(Windows, MinGW)

Building basic

Before building, edit build/config/MinGW. Delete -mno-cygwin as newer versions of g++ treat it as an error. Choose the desired minimum WINVER.

By default make will build the library for static linking. This is in general a good choice since you will likely be writing you own code on top of the library and use the few components that you need and you can choose to export whatever you want and build your own much smaller DLL instead of linking at run time with a kitchen sink DLL that has everything. It is then not obvious that when you compile your own code with Poco headers you must define POCO_STATIC. If you didn't the linker would complain about not able to link with any Poco classes. If you do -E to look at the pre-processor output you will see that without defining POCO_STATIC the included Poco headers will declare the classes to be dllimport and no wonder you can't link them against the static libraries you built!

The Poco binaries with names ending in d (e.g. -lPocoFoundationd) are debug builds with symbols not stripped out. For a smaller build of your own executable link against the ones without the d ending (e.g. -lPocoFoundation).

Zip

For some reason (an oversight?) Zip component is not included in the basic distribution package even though it does not have external dependencies. To remedy this, I downloaded the -all package. I copied the existing Makefile to Makefile_all so as not to make all components by default. I then hand edited the Makefile to remove components other than Zip from COMPONENTS definition and removed all but Zip-libexec from the libexecs target. Also I remembered to copy over the config/MinGW from the section above. Now make -j 4 install did the job of adding the Zip component to my previous basic installation. The Makefile also let me define OMIT but I didn't take that approach as I would have to enter all the components I don't want for this build. I took the more expedient route. I renamed the hand edited Makefile to Makefile_Zip just to be clear.

Filesystem

To ensure that the parent directories exist there is a convenient member function createDirectories to call. However if I call directly on a File object it will treat the whole path as a directory. Oddly Files don't have a parent member function, so I have to go back to a Path object for the parent() call. So this part of the interface is a bit rough.