On 03/25/2015 05:22 PM, Noel Maersk wrote:
> On Wed, Mar 25, 2015 at 12:41:20PM -0700, Eric Voskuil wrote:
>> All of the dependencies can be isolated to a prefix directory, including
>> boost. The installer of any repo takes care of this with two options:
>>
>> $ ./install.sh --build-boost --prefix=<path>
>
> Yup, I was thinking more of the general instructions for those few who
> want to work with the code, as compared to deploying. Think
>
> https://wiki.unsystem.net/en/index.php/Install_entire_toolchain
>
> - which I'll be getting to updating, probably tomorrow...

The installer is just as much for working with the code. It pulls down
all dependent repos, builds them using the same instructions and allows
for configure options to be passed through. It just saves lots of typing
and prevents inconsistencies. This was originally why I wrote it - to
save myself time while developing.

The standard make instructions for each repo are also provided in each
respective repo, as well as a reference to the the necessary
dependencies. So for someone wanting to execute each step manually,
there should be no gaps.

It's very hard to keep accurate external sources of information, so
there is always drift. IMO it would be a better use of our time to
improve self-generating documentation and work to keep documentation
that must be manually maintained (such as examples) close to the code.

When I see errors in the external documentation, which is quite often, I
don't deal with them because it's just too hard and feels
counterproductive. When there are issues in GitHub content, people
create an issue and/or make a pull request, or comment on a commit (as
you did today) and it gets fixed quickly. There is a workflow, history
and people get credit for their contributions.

This is not to say I don't appreciate the many external contributions,
or that I don't value the relationships with Unsystem or Dyne. I would
just like to find a way to improve our process. Libbitcoin has
tremendous potential but that potential would be better realized if
information was better organized.

>> This also minimizes the boost build to only the required components.
>>
>> The minimum boost requirement is 1.50 presently, because of a
>> boost-locale bug in 1.49.
>
> ... and the READMEs, too, - there's still "1.49" here and there.

Yes, just another example of the never-ending drift. This is why I spend
so much time on libbitcoin-build. By generating related artifacts from a
single source drift is eliminated.

Soon we will have *all* files excepting sources generated in full across
all repos. This includes published master include, version header, swig
interface, scripts for updating swig bindings, swig generated sources,
m4 scripts, all GNU docs (using git for history), all autotools
artifacts, Travis build, installer script, and package config.

Generating API documentation from headers consistently is a next step.
In the same vein I would like to get code coverage automated and create
a deterministic build process. This takes quite a bit of time away from
writing code, but there's no point in writing code if it doesn't get
used, and this quality-related work is important from that perspective.

>> GCC 4.7 should still work, although the Travis builds test on 4.8. SX
>> and Obelisk never had CI builds, so it's not really a different
>> situation there.
>>
>> We could downgrade the Travis configuration and make 4.7 support
>> official, but I haven't had a compelling reason to do this. I haven't
>> tried clang < 3.4, but might be able to do the same there.
>
> Me neither.

I spent some time on this yesterday. GCC 4.7 works but we do not use it
in the Travis builds because it is too slow in compiling large amounts
of static data. It times out on Travis even in the libbitcoin build. GCC
4.9 works, but is not materially faster than 4.8. If we aren't using 4.7
in Travis builds we can't really advertise support for it, and it's
getting really old. The boost issue has come up before as well, and
we've always worked around it. But this time I didn't have any
reasonable resolution. I suppose at some point Debian stable will catch
up, but in the mean time it's workable.

e