Add options to support more complex projects

[psettle]

Sorry about all the formatting changes, I have black formatting setup on my IDE and forgot to disable it. I can redo without the formatting if needed.

[MarcosCosmos]

Hi, thanks for this - its great to see the tool is still useful after so long.

I'll have a look at the PR over the weekend and either accept it or let you know if there are any issues.

Not too worried about formatting.

[MarcosCosmos]

The addition of include path specifiers is great, thanks!

I'll set up some test integrations before progressing to accept it - it would be great if you could add some test cases specific to the custom include paths, but I can do that myself if need be.

In the meantime, can you explain your rationale for allowing -i to be specified repeatedly?

I am concerned that it has little benefit and would largely facilitate malconfigurations in which the bundled/uploaded code differs from the code executed locally. Moreover, since there are many on CG who are still very much learning, there may be some KISS value in a single point of entry to encourage users to make sure their local setup actually incorporates all the snippets that get uploaded.

If there is a sound justification, then I would like to be more explicit (both in the readme and in --help) about when it should and should not be used for the benefit of those who are still learning - advanced users can always inspect the code and make their own decisions after all.

[psettle]

Oh sorry I didn't notice the test folder, I'll see what I can do to add a test.

As for the multiple -i arguments, I am using it to support bundling more well-structured projects, with source split into many .cpp files. It ends up bundling the .cpp together in a way sort of similar to how a proper compiler would. It could even be used pretty easy to pull an external c/cpp library into a codingame submission easily too.

There is some risk to getting naming collisions between local static declarations that a compiler wouldn't run into, but with good practice on C++ namespace usage or C naming that shouldn't really come up either.

For example, here's a project that consumes this feature: https://github.com/psettle/madmax/blob/master/makefile
I have the makefile setup to compile the program as a normal C++ program (i.e. from several object files), but also to bundle it, minify it, and compile it again as part of the build process.

I could change it to use the -i argument only once, and then expose a new argument for 'extra source files' maybe? That would reduce the risk of a novice user misunderstanding the config.

[MarcosCosmos]

Thanks for that - and I'm not surprised, seeing as I had not set up CI tests yet. I'll probably script a script to convert the existing tests into unit tests in a formulaic way but it will be very formulaic (e.g. each existing file's inclusion sets a static flag used by assertions in the test call); The existing tests work fine, but it would be good to have the automatic listing of which cases pass/fail.

Regarding the .cpp splitting, I think I see what you mean now - I originally wrote the bundler to infer .cpp files from header files instead of manual specification (and personally use templates so much I almost forgot about it), but there is no formal or language-compliant reason to expect .cpp files to mirror header files, so the use case is fully valid.

So, we currently have the existing behaviour that infers .cpp files, and a more formal option that uses manual listing.

An acceptable solution might be to make the two modes of operation mutually exclusive to avoid conflicts? I.e. have the -i flag as a once off and add a new one as you suggested, but also make it so that you can only specify one or the other?

That said, if we are aiming for fully versatile/compliant bundling, it might be better to directly parse make and/or cmake files instead? What do you think?

I will note, largely to warn readers, that pulling libraries into a CG submission is strictly forbidden, at least last I checked.
Edit: I believe restrictions apply to contest submissions, but less so to open arenas.