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@windriver.com] Sent: Wednesday, September 05, 2018 11:02 AM To: Dean Troyer; Saul Wold Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
-----Original Message----- From: Dean Troyer <dtroyer@gmail.com> Sent: September 5, 2018 1:54 PM To: Saul Wold <sgw@linux.intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] unified build command suggestions
On Wed, Sep 5, 2018 at 12:16 PM, Saul Wold <sgw@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@gmail.com
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss