corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Added build instructions.
Date Thu, 12 Feb 2015 11:15:52 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message