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 Wed, 11 Feb 2015 20:00:56 GMT
 -- 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.
</orcmid>

rgds
jan I.

> </orcmid>
>
>


Mime
View raw message