Overview
Features
Download
Documentation
Community
Add-Ons & Services

A long path to builds; An epic in many parts.

Please post support and help requests here.

A long path to builds; An epic in many parts.

Postby marphod » 23 Jul 2012, 00:05

tl;dr - I can't build Poco. I can't build it with my box, I can't build it with a fox. I can't build them here or there, I can't build poco anywhere.
(Okay, I have some level of success, but I liked that line enough to keep it. Keep in mind I started this post over a week ago.)


In this epic, our hero did an analysis of various F/OSS C++ platform libraries and decided from a 10k meter view, that he'd like to try out poco. It had the functionality he wanted, and did so with a more elegant object model and without the cruft of the other options he found. This was after using Boost for a while (and getting thoroughly sick of an object model where related classes had no common ancestors, nor consistency between modules), and looking at other alternatives including ACE, APR, CODA-OSS, Gnu CommonC++, Neptune C++, Nspr, Platinum UPnP, PortableTypes, QtCore, SourcePro C++, VRJuggler PR, and wxBase. (Yes, some of those are not actually F/OSS).

After looking at these, our hero tried to actually BUILD the POCO portable runtime. And thus the epic begins.

Table of contents:
  1. Top of Post
  2. Table of contents
  3. Build Platforms
    • Primary Platform: Wintel
    • Secondary Platform: Cygwin
    • Other Platform: OS X (Mac)
  4. Current Status
  5. Lessons Learned, so far
  6. Open Questions

----------------------------------------
Build Platforms:
Primary Platform:
OS: WinXP 64bit SP2[1]
Compiler: VCExpress 2010
SDK/Build framework: Windows SDK 7.1, .Net 4, etc[2]
Installed 3rd party components: OpenSSL, MySQL, MS SQL[3]
Targets:
buildwin.cmd 100 build shared both Win32 samples vcexpress all
buildwin.cmd 100 build all both Win32 samples vcexpress all
buildwin.cmd 100 build all both Win64 samples vcexpress all

Secondary Platform:
OS: WinXP 64bit SP2[1] -- Cygwin 1.7.15-1
Compiler: gcc 4.7.0 (locally compiled)
Installed 3rd party components: OpenSLL, MySQL, MS SQL[4]
Target: make -j4 -s all

Other Platform:
OS: MacOS X 10.4.11 (PPC-G4)
Compiler: gcc 4.0.1
Target: make -s all
---------------------

    Current Status:
    • WIntel
    • Debug/Release Shared Win32: Samples build, libraries build, WinTestRunner and testsuites do not build.
    • Debug/Release Statics/Shared Win32: Samples build, libraries build, WinTestRunner and testsuites do not build. NetSSL_OpenSSL/Samples/Mail does not build for release_static_mt, debug_static_mt, or debug_static_md
    • Debug/Release Statics/Shared Win64: Currently on hold, as I need modify my build script to be build-target aware to change paths for external libraries.
    • cygwin
    • Builds, I Think? Binaries are built, 'make install' installs. I've not gotten beyond that, yet.
    • I have no idea how to run the unit tests, there is no make target to execute the unit tests as far as I can tell, and when I run the testrunner/testrunnerd.exe executable file I get no output (I've tried a lot of command line flags, including --print, -p, -print, -h, -help, --help, -?, --?, /?, /help, /print, /h, /p).
    • MacOS X
    • Fails to find libraries during link steps
    • As far as I can tell, there is no way to configure to acknowledge PPC architecture, rather than x86. (see Open Questions)

---------------------

    Lessons learned so far:
  • The file contents in a download of the source tree is not consistent. (see viewtopic.php?f=12&t=5464 ) This is a problem, but is surmountable.
  • Much to my chagrin, I found no way to use the cygwin installs of OpenSSL and MySQL as part of the Windows build. This makes my personal build process more annoying, but is probably not a POCO issue.
  • There is no where in the documentation that I can find that explains how to run the unit tests on any platform. Command line options, expected output, etc. This is a problem.
  • It is documented, admittedly, but WHAT ON EARTH is stopping the unix-like builds from working on directories with symbolic links? This is a pain, as my /home directory is usually a separate partition and if often symbolically linked to /home (rather than using /home as the mount point).
      Wintel:
    • The windows command line build script does not report errors nor stop on errors. This is a problem.
    • Building in a directory that is mounted via SMB (from the aforementioned Mac) is problematic -- I've gotten all sorts of file permission issues (files could not be created, could not be read when existent, could not be found when existent, etc.). This may be an issue with my server hardware or windows XP. Bloody annoying, but probably not a POCO issue.
    • Poco continues to have references to afxres.h, afxmt.h, and afxwin.h, which are not part of the vcexpress package. This is a problem, but is surmountable.
    • buildwin.cmd is annoyingly brain dead. It does not detect vcexpress v standard installs, gives sometimes unhelpful messages, and doesn't list the valid build targets that need to follow the options. The various compiler-specific build scripts do not take obvious parameters, if one were to want to invoke them directly. The options to buildwin.cmd have to be in a specific order, seem to be mandatory, and do not seem to take environment settings for defaults. This is a problem, but is surmountable.
    • As WinTestRunner requires AFX, all the test builds will fail (without a full MSVisStudio install) . This is a problem.
    • There does not appear to be a way to built and run unit tests in a VC Express environment. This is a problem.
    • Don't have both the 32 and 64 bit windows version of OpenSSL/MySQL in your lib path; the errors will be impenetrable.
    • Make sure to have the CORRECT version of OpenSSL/MySQL in your lib path; the errors will (again) be impenetrable.
    • The staging area for the 32 and 64 bit builds are the same -- which is potentially a problem if a compiler creates distinct files for 32 and 64 bit builds. (obj, pdb, idb, etc.)
    • Cygwin
    • There's a bug in my local copy of /usr/include/iodbcunix.h which has 'typedef unsigned int DWORD;' rather than 'unsigned long' like the rest of the windows and GCC headers.
    • It'd be nice if there were a make target for running the unit test.
    • It'd be nice if, even using the -s flag, there were any form of output on successful execution of 'make install'

---------------------

    Open Questions:
  • Why is there no documentation on how to run the unit tests?
    • Wintel:
    • Is a Wintel vcexpress environment (without ATL/AFX/the rest of MSVC) part of the standard test build environment? And if not, why not?
    • Is building both a 32 and 64 bit version from a single source tree on Wintel a supported environment and part of the test builds? And if not, why not?
    • Is there an easy way to tell my wintel build to use the same test suite/tools as non-wintel? I'd really like to build them.
    • MacOS X
    • Is PPC MacOS X supported? I can't find a yes or no anywhere.
    • If it isn't supported, what is the reason? if it is, how do I tell the build system to build for the correct platform?


-------------------------------------
Footnotes:

1: There is no SP3 for WinXP 64 bit.

2: Full SDK details:
MS Windows SDK 7.0a 32 bit
MS Windows SDK 7.1 64 bit
MS .Net Framework (2.0SP2, 3.0SP2, 3.5SP1, 4)
MSVC++ Redistributables: 2005, 2008, 2010, each 32bit and 64bit.
MSVC++ Runtime 2010
(Latest patches for all)

3: Third party installs for wintel
OpenSSL 1.0.1c Win32 & x64
MySQL Server 5.5 (Connector C++ 1.1.0)
MS SQL 2008 (64bit)

4: Third party installs for cygwin:
OpenSSL 1.0.1c-1
MySQL 5.5.21-1 (odbc-mysql 5.1.10-1)
marphod
 
Posts: 2
Joined: 27 Jun 2012, 22:23

Re: A long path to builds; An epic in many parts.

Postby alex » 23 Jul 2012, 01:29

Short answer to your questions is: we do not have a dedicated build system maintainer, documentation writer, or release engineer; we scratch our own itches and do the best we can for the rest of you out there.

Everyone is welcome to help and contribute. That said, we'll be happy to make you happy; we will gladly accept your help with workload needed to rectifying the above mentioned issues. If you are seriously interested in helping with the workload for the upcoming 1.4.4 and 1.5.0 releases (which almost certainly will not happen week from now as was planned), let me know. My email is at(alex, dot(pocoproject, org))
alex
 
Posts: 1130
Joined: 11 Jul 2006, 16:27
Location: United_States


Return to Support

Who is online

Users browsing this forum: No registered users and 1 guest