ibmi-bob (`makei`) shim

[worksofliam]

I would like to build a makei shim to re-implement ibmi-bob with the Source Orbit backend. Here are some of the benefits to this:

• When installing Source Orbit, you'd get two commands: the standard so as is, and this makei shim.
• The shim will be a drop in replacement for makei and will support the same parameters.
• This shim will generate the makefile and execute it automatically.
  • Perhaps we will have a CLI option to only generate the makefile
• Source Orbit can automatically resolve dependency trees, meaning Rules.mk would be completely optional.
• You may still use Rules.mk to define customer properties for specific objects, or hardcode dep trees for languages not supported by Source Orbit (like C and COBOL).
• This makei shim will continue to support use of iproj.json and .ibmi.json project metadata.
• We can add automated tests using our testing framework.
• We will have a single codebase for both ibmi-bob and Source Orbit.

[edmundreinhardt]

@worksofliam My suggestion is that we have a -so option on BOB's makei and in that case the Rules.mk are no longer necessary because they can inferred from SourceOrbit (generated into .deps)

That way there is no duplication of effort between the two projects. SourceOrbit supplies the dependency information so users don't have to maintain them manually any more. If they prefer to maintain them (because of performance reasons when rescanning large project) they simply do not use the -so option.

[worksofliam]

Another idea I have considered is not doing this at all, but making the -bf make option take the .ibmi.json and Rules.mk files into consideration.

[JDubbTX]

Love this idea. I've been using Bob quite a bit lately, but haven't (as yet) tried out source orbit - so don't put too much stock in my response. With Bob, it can be a bit tedious to set up the Rules.mk files - so it would be awesome to have them automagically created. However, the Rules.mk files do offer the flexibility of changing build options for programs that are special. We developers like to maintain a sense of control and not hand over our lives to the robots completely. Its also nice to have a reference to 'how was this object built' - so maybe just create the Rules.mk file anyways. Have you seen the number of parms on a CRT* command? I'd like to see Bob eventually handle ALL of them, even the ones that are seldom used. Also, I like it that you can have source members that are skipped over by commenting (or not including them) in Rules.mk

[edmundreinhardt]

So to be clear, so can maintain existing Rules.mk files by updating/adding dependency information, while preserving compile parameter overrides?

[worksofliam]

@edmundreinhardt Yes, no matter which direction we go here with Source Orbit, we will respect parameter overrides and hardcoded dependencies.

[worksofliam]

Update to this: the attached PR implements the functionality I actually wanted.

• -bf make still works as it did before. No changes there. I will refer to this as the 'make build' from now.
• The make build now takes into account the .ibmi.json and Rules.mk files (it already worked with iproj.json)
• The make build will use the automated Source Orbit dependency tree as the basis for the makefile (like before), but will now overlay the hardcoded dependencies in the Rules.mk file. It will also respect the custom attributes (command parameters) when generating the makefile.
• It will also take the .ibmi.json file into consideration. Right now, it only supports the tgtCcsid property, which sets the target CCSID of the object being compiled for all objects in the same directory as the .ibmi.json.