corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Added build instructions.
Date Thu, 12 Feb 2015 16:22:07 GMT
At the bottom, below, Jan replies

	most of what you describe here, belongs (in my opinion)
     in the wiki or on the web pages, not as a short 
     instruction in the code itself.

     I look forward to see your proposals for the above items.

I stated in my last comments that I believe these instructions are appropriate in the code
base itself.  That's because they will change with the code base.  This way, every released
source-code archive carries the instructions that apply precisely for it.  Part of verifying
a release is confirmation that those instructions do indeed work for that release.  I see
this as important for new users for the code and new, possibly inexperienced, contributors
to Corinthia.

A wiki shows a current set of instructions, for some degree of "current."  It is
possible to link to a specific version on a wiki (though not sure about the CMS we use), and
I have suggested that the build instructions could include links for drill-down cases (such
as prerequisites for building).

Finally, I believe I have pointed out defects in the instructions as they now exist.  The
mention of the .sh scripts, which are no longer current, is an important one to repair.  And
the fact that the instructions appear to be specifically for windows needs to be dealt with
(i.e., that is the only use for the current externals).  

I shall now be silent on this matter.  I don't see how to reconcile what I see as important
with what is being done. I have no desire to obstruct any effort. I am just not subscribing
to it.  This exchange has helped sharpen my own thinking on packaging builds for my personal
development efforts though.

 - Dennis

-----Original Message-----
From: jan i [mailto:jani@apache.org] 
Sent: Thursday, February 12, 2015 03:16
To: dev@corinthia.incubator.apache.org; Dennis Hamilton
Subject: Re: Added build instructions.

On 11 February 2015 at 21:00, Dennis E. Hamilton <dennis.hamilton@acm.org>
wrote:

>  -- replying inline below to --
> From: jan i [mailto:jani@apache.org]
> Sent: Wednesday, February 11, 2015 10:55
> To: dev@corinthia.incubator.apache.org; Dennis Hamilton
> Subject: Re: Added build instructions.
>
> On 11 February 2015 at 19:34, Dennis E. Hamilton <dennis.hamilton@acm.org>
> wrote:
>
> >  -- replying below to --
> > From: jani@apache.org [mailto:jani@apache.org]
> > Sent: Wednesday, February 11, 2015 09:18
> > To: commits@corinthia.incubator.apache.org
> > Subject: incubator-corinthia git commit: Added build instructions.
> >
> > Repository: incubator-corinthia
> > Updated Branches:
> >   refs/heads/master 9e8e44c36 -> c94ae5dd5
> >
> > Added build instructions.
> >
> > <orcmid>
> > [... ]
> >     2. The externals are only meaningful for Windows
> >    builds, whatever platform is targeted for the
> >    compilation.  It might be possible to shorten that
> >    lengthy list of CMake options to ones that make
> >    sense for this case.
> >
> Which long list ??? I only use -G
>
> <orcmid>
>   I mean the lengthy list of <build> cases for -G "<build>"
>   Also, it is not always necessary to have this, CMake on
>   Windows seems to do a good job finding the installed
>   development software.
> </orcmid>
>
>
> >
> >     3. Because of platform differences, it might be
> >    better to separate out the build for each platform
> >    into a separate build text file.
> >
> Why, there are no differences. All platforms need to do a "cmake -G"
>
> <orcmid>
>    Not all platforms need the externals.  If these
>    instructions are for building code that runs on
>    Windows, specifically, these build instructions
>    should say so.
>
>    The -G <build> is going to specify a build
>    system.  In this case, we need to specify
>    only build systems that work for making
>    a Windows target.
>
>    Or are you lumping all platform targets into
>    these single instructions?  I don't think that
>    will work because of differences in external
>    dependencies at the moment.
>
>    I would definitely separate these by target
>    of the build.
> </orcmid>
>
>
> >
> >     4. I would also separate out the builds we test
> >    with for confirming a buildable release and those
> >    build options that are not tested but that
> >    Someone might experiment with.  I would put the
> >    VS 2015 build in that category until VS 2015
> >    graduates from technology preview to a release.
> >
> ???? Are you mixing build instructions with our buildbot setup ?
>
> Build instructions, only tells new developers how to compile corinthia on
> their platform....nothing about tested/released platforms, that should be
> in other documents.
>
> <orcmid>
>    Since I never use a buildbot, that never entered my
>    head.  No, I meant for a source release, building
>    of the code and obtaining a working artifact
>    must be repeatable.  In that case, we need to say
>    which targets and build processes we have confirmed
>    to be successful.
>       Anyone reviewing a release could test those cases
>    and would not have a complaint for combinations that
>    we have not confirmed ourselves.  This is part of
>    Getting to project maturity.
>       I think new developers need to know which
>    configurations we claim to be working so they can
>    attempt to replicate that before going into
>    uncharted territory.  I would definitely reflect
>    that scope in build/ because it is part of the
>    source-code release and it is nice to version-
>    control it along with the source.
>       I am not talking about the convenience binaries
>    but what a new developer can use as guidance with
>    respect to what has been confirmed to work in these
>    instructions with the given source release.
>
>       Does this make more sense?
> </orcmid>
>
>
>
> >
> >     5. With regard to VS builds, it is useful to
> >    know the simplest versions (e.g., Express or
> >    Community) that is the tested case.
> >
> That could be information in the general README file.
>
> <orcmid>
>    I am not certain where a general README file goes,
>    but I would hope that it drills down to further
>    detail by referencing the places where the details
>    matter, such as specifics for build instructions,
>    Ideally in the build/ folder.
> </orcmid>
>
>
> >
> >    Hmm, it might be good to have a job jar about builds.
> >    this note will have to be good enough for starters.
> >
> What do you mean by a "job jar" ?
>
> I think you see a far bigger purpose of build_instructions.txt than the
> intention was.
>
> <orcmid>
>    A "job jar" is a list of little work items.  The metaphor
>    is with a glass jar in which little items are written on
>    small pieces of paper and placed in the jar.  It is a
>    household term.  When a member of the household is looking
>    for a small chore, one of the pieces of paper is removed.
>    Sorry, it may be an Americanism.  Think "TODO" list.
>
>    Yes, I think I do mean a more complete purpose for the
>    build instructions, especially for newcomers including
>    students, beginners, and hobbyists.
>
>    I noticed that the prerequisites are not described, for
>    example.  I.e., have cmake, etc.  Even if not here, then
>    cross-reference to where there are details like that.
>

most of what you describe here, belongs (in my opinion) in the wiki or on
the web pages, not as a short instruction in the code itself.

I look forward to see your proposals for the above items.

rgds
jan i.


> </orcmid>
>
> rgds
> jan I.
>
> > </orcmid>
> >
> >
>
>


Mime
View raw message