Re: [cpp-netlib-devel] Compile-time Reduction Effort

[Glyn M. <gly...@gm...>]

On 26 October 2010 06:33, Dean Michael Berris <mik...@gm...>wrote:

> On Tue, Oct 26, 2010 at 2:59 AM, Glyn Matthews <gly...@gm...>
> wrote:
> > Including the compile time
> > problem and making cpp-netlib strictly being header-only has very few
> > benefits.  I would suggest a better use of our focus should be on
> > portability.
>
> Yeah, the compile time problem is really brought in by Boost.Spirit's
> Qi (and consequently Boost.Fusion and Boost.Proto). Although it is
> portable already as it is now, right?
>

Maybe I need to clarify what I meant "portable"... I mean that with each
version upgrade of cpp-netlib we don't preserve backward compatibility
either with older versions of Boost or of compilers.  This pretty much rules
it out for most embedded systems who have to rely on older compilers (for
one project not so long ago I was still using gcc 2.95).  I think there is a
strong argument in favour of preferring this kind of stability than to using
the latest and greatest from Boost (fun though it might be for the
developers).


>
> > Additionally, I have been doing a lot of development in embedded systems,
> > where the long compile times and large binaries that are generated pretty
> > much rules out using cpp-netlib.  This is a shame, because this is an
> area
> > where cpp-netlib can provide a lot of benefits to developers.
> >
>
> Are you not stripping the binaries created by cpp-netlib? In Debug
> mode, yes you will have problems with the debugging symbols eating up
> the output binary.
>
> Also, since we still depend on Boost.Lexical_cast that does depend on
> the STL io streams library, that will cause the binaries to be pretty
> large. We might want to try using Jeroen's construe_cast in places
> where we use lexical_cast.
>
> The long compile times can really be addressed by precompiled headers
> especially if you're using GCC. Clang, well not so much because
> precompiled headers support is still a little ... well... iffy at this
> time. :D
>

and MSVC?  I know it supports PCH of course but how does it differ from GCC?
 Will this affect design decisions?

>> > I'm nearing the completion of the asynchronous server that invokes
> >> > request handlers in a thread pool and although the compile times have
> >> > been reduced in the HTTP client side of things I would really
> >> > appreciate some CMake kung-fu from people on the list to incorporate
> >> > precompiled-headers (so that we can make that part of the install step
> >> > in 0.8).
> >> >
> >>
> >> Compile time *is* an important issue, but the beauty of a header library
> >> is that there is no install step- you just copy the files into your
> >> directory tree.
> >
> > But there is an install step, because of the dependencies that cpp-netlib
> > has - and will have: in developing the XMPP client I'll be linking to an
> XML
> > parser library and TLS library.  Other protocol implementations will
> bring
> > other dependencies and we'll have to deal with those too.
>
> Yeah, this is going to be the test of having an install step. :D
>
> > Regards,
>
> Thanks for the comments Glyn, hope mine help convince you that
> precompiled headers and changes to cpp-netlib will be good for users
> (and embedded systems). :)
>

I am not going to argue too forcefully for shipping cpp-netlib as a library,
since we've already been marketing it as header-only since it's inception
and I think it does have merits.  My main motivation is for better
stability.

Glyn