-- 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. </orcmid> rgds jan I. > </orcmid> > >
