[Starlingx-discuss] [Build] unified build command suggestions

McKenna, Jason Jason.McKenna at windriver.com
Wed Sep 5 18:02:06 UTC 2018



> -----Original Message-----
> From: Dean Troyer <dtroyer at gmail.com>
> Sent: September 5, 2018 1:54 PM
> To: Saul Wold <sgw at linux.intel.com>
> Cc: starlingx-discuss at lists.starlingx.io
> Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
> 
> On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw at linux.intel.com> wrote:
> > I agree with this, similar to what git and some other tools do also, I
> > like the examples you provided below.
> 
> Sooooo..... git should mostly not be used as an example UI for most
> purposes, it is a bit of a mess :)
> 
>   git remote add ...   (ok, but...)
>   git branch -m ...     (not branch move?  branch is sometimes an
> object and sometimes a verb depending on the options!!)
> 
> > I think it would be better if was more like
> >
> > stxb build iso
> > stxb build all
> >
> > I know this is different than the mirror actions above, but the "all"
> > does not make sense to me in this usage.
> 
> This is the what-comes-first question, the object or the action?  VMS is still
> leaking from my brain in that I also prefer the action (verb) to be first.  OSC
> reversed itself 5 years ago because of the bash-completion issue, we use cliff
> to implement the command parser (built on top of argparse) and doing verb-
> first and bash completion turned out to be a mess.  That is an
> implementation driving design, which is not always great, but was acceptable
> to the team at the time.
> 
> Which ever order is settled on, PLEASE make all commands the same.
> The UX studies we did with OSC always showed this consistency to be very
> important to both new and experienced users.
> 

+1 on consistency :)

I think we need discussion around what we're really trying to accomplish.  Going back to Cesar's initial proposal, the problem he wanted solved was that his team felt that there were too many commands required to produce an ISO after you've downloaded the mirrors (generate-cgcs-centos-repo.sh, build-pkgs, build-iso) and wanted to wrap those in a single command.  Please correct me if I've misstated the problem, Cesar.  Furthermore, I think you were looking for a command which did the steps that a developer would execute and not do the steps that a developer would not (downloading the mirror, is intended to be done at a per-site level, not a per-developer level, and would not necessarily be included in the single-command).  Finally, the command was intended to be expandable and adaptable in the future (again, please correct me if I've misstated anything).

Other than the "meet all conceivable future needs" requirement, I don't see much that couldn't be done with something like a Makefile:
make mirror
make environment
make build
make iso

especially if you have the "iso" target depend on the "build" target which depends on the "environment" target, etc, then the whole process boils down to one "make iso" command for a developer (2 commands if they have to download the mirror themselves).  Note that I'm not proposing "make" as a solution, I understand the concern that make wouldn't meet our needs in the future, and make can be less than pretty.  I'm more engaging in the thought exercise of "what problem are we really trying to solve and has anyone solved it in the past"
 
If we're wrapping or re-writing the build commands to make it simpler/easier for a developer, we should define proper use cases and make sure we're solving the right problems.  To go off on a tangent, I find the illegible output of the build commands to be much more a stumbling block than the fact that I have to execute 3 commands rather than 1 to produce a build.


> dt
> 
> --
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


More information about the Starlingx-discuss mailing list