On 11 February 2015 at 21:00, Dennis E. Hamilton <[email protected]> wrote:
> -- replying inline below to -- > From: jan i [mailto:[email protected]] > Sent: Wednesday, February 11, 2015 10:55 > To: [email protected]; Dennis Hamilton > Subject: Re: Added build instructions. > > On 11 February 2015 at 19:34, Dennis E. Hamilton <[email protected]> > wrote: > > > -- replying below to -- > > From: [email protected] [mailto:[email protected]] > > Sent: Wednesday, February 11, 2015 09:18 > > To: [email protected] > > 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> > > > > > >
