Shipping a static splinter library and binary frontend

[EliRibble]

I attempted to have conversations with maintainers at the ninja project on ways to modify ninja to make it possible for clients to write their own frontends, or to configure the frontend behavior of ninja. Here are some examples:

• Second, heavy binary issue from nico
• My large experimental PR that creates a library
• An earlier attempt at an external frontend

I failed to get any interest from ninja maintainers. This project seems more lively. Would this project be interested in splitting out a static library that could help clients to create their own frontends? Specifically I'm proposing:

1. We need a system for doing logging that allows library clients to capture log messages and emit them their own way. jonesmz suggests a design similar to boost, but constrained to a few points:
   • Multiple backends, so I can dynamically target log files, console output, or a logging server on the network, as I feel like at runtime.
   • Dynamic variables captured with each log statement, which can include the current functions name, or the current timestamp, or what have you.
   • Easy to replace the functionality using macros. E.g. I can provide my own logging statements that customize what gets logged, by defining a macro that i call.
2. Introduction of a splinter namespace. This is just nice when you're a library. Removing 'using namespace std' anywhere it is still used in headers (if applicable).
3. Separation of a ui layer which is in charge of parsing commandline arguments into various structs for holding configurable behavior. Pass these structs into configurable functions to change behavior.
4. No more logic for "things are going badly, exit now". So no ExitNow function.
5. Removal of global state - some gets pushed into State, which can be reset on rebuild, some gets pushed into the new Execution class.
6. Introduction of public header files. They'll live in some dedicated directory and we'll need to commit to some kind of way to avoid constantly breaking changes.

I'm less familiar with this fork than I am with ninja, so forgive me if some of these don't apply. I'm just trying to be clear about intent so we can discuss whether or not this is desirable from a common understanding.

[jonesmz]

@EliRibble

This project is primarily a series of patches that I want to get included into Ninja directly.

That being said, I've had all of the same frustrations that you've just expressed with regard to working with the Ninja project, and it's maintainers.

I'd be more than happy to work with you to convert Ninja / Splinter into a library, and then plumb it with the feature enhancements that you detailed in your issue description.

The first thing I'd recommend doing is carefully reviewing the different branches in this repository. The branches prefixed with a number are the "main" branches of this project. Each prefixed branch is ordered from 0 up to indicate the order of the branch.

Branch 1 directly builds on branch 0. Branch 2 builds on branch 1, etc.

Branches without a numeric prefix are "scratch work" that you can probably ignore.

Removing 'using namespace std' anywhere it is still used in headers (if applicable).

Removing using namespace std is branch 1-std-namespace, so I was already way ahead of you there.

Please feel free to open new issues if you have ideas.

I'm also open to changing the way I've been structuring my work, to use something other than branches, if you have any suggestions.

[jonesmz]

I suppose a few more thoughts are in order.

One concern that I have is that I don't want to completely discard the possibility of work in this fork getting upstreamed into the ninja project. The more divergence we have with upstream, the more difficult it becomes to adopt improvements submitted upstream.

What might need to happen is that the patch series that I've developed (all intended to be upstreamed, of course) needs to be maintained in a different repository. For example, we could make something like "ninja-next" for that work to live in.

And then splinter can be a proper fork of ninja-next, that works on library-ification.

just spitballing here, I don't know the right answer.

[EliRibble]

Thanks for the detailed thoughts. Yeah, I can see your point. It's wise to want to keep things in a generally-upstream-able state.

I like the idea of ninja-next that contains branches meant for upstreaming. I'm not crazy about the idea of maintaining two projects in the hopes that some day the ninja maintainers will be interested in the work.

What about a process like this: Create an issue that matches each branch for ease of tracking what the branch is for. Branches should be kept in github. When the branch is complete, merge it into master. If the ninja project is interested we should still have the history of the various issues and their matching branches and they could merge in individual branches. But the master for splinter then has the various updates and we could cut releases from master that includes all the features. That would also help to avoid having a tangled history of keeping track of which branches are based on each other.

I'm assuming a few things about how GitHub works that I can't back with actual experience. I should probably run some experiments.

What do you think?