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

Wed Sep 5 22:41:20 UTC 2018

Thank god for autocomplete *clicks tab* :P 

Regards 
Cesar Lara

-----Original Message-----
From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] 
Sent: Wednesday, September 5, 2018 5:30 PM
To: Arevalo, Mario Alfredo C <mario.alfredo.c.arevalo at intel.com>; McKenna, Jason <Jason.McKenna at windriver.com>; Dean Troyer <dtroyer at gmail.com>; Saul Wold <sgw at linux.intel.com>
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions

My $0.02, for what it's worth.  The name stx-build-tool is too long.  +1 to stxb from a previous note in this thread.

       brucej

-----Original Message-----
From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo at intel.com]
Sent: Wednesday, September 5, 2018 3:13 PM
To: McKenna, Jason <Jason.McKenna at windriver.com>; Dean Troyer <dtroyer at gmail.com>; Saul Wold <sgw at linux.intel.com>
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions

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

_______________________________________________
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