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

Arevalo, Mario Alfredo C mario.alfredo.c.arevalo at intel.com
Wed Sep 5 22:12:49 UTC 2018


Hi team,

Related to the tool name, a good point was mentioned, StarlingX is the core project, “stx” should be
reserved for the core things. The building tool will be called “stx-build-tool” or “stx-bt” and it is good
to keep consistency with the current stuff.

And about the different options/subcommands proposed by Jason, they can exist, the idea is to cover
both sides, develop and user sides.

It is possible to have users that maybe would not like to involve in the development process and they
just want to get ISO image, this is a valid point and our build tool should allow that way, the next proposed
commands should be enough for a “Quick user guide”.

$ stx-build-tool mirror create
$ stx-build-tool iso build

By the other hand the developers need more granularity about the processes, then the subcommands
proposed by Jason are welcome. The implementation of this script will be modular, then it will be easy
to implement relevant and needed subcommands in a future just calling the required functions.

An related to the comment about Makefile rules, I think  it could be better to use shell commands directly
instead to wrap them in a Makefile, due to it is easier to customized values on command line. Using
Makefiles it is possible to do it too, but I think it is a little less friendly.

Best Regards.
Mario.
________________________________________
From: McKenna, Jason [Jason.McKenna at windriver.com]
Sent: Wednesday, September 05, 2018 11:02 AM
To: Dean Troyer; Saul Wold
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions

> -----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
_______________________________________________
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