Should I decouple useful code from boilerplate?

At work most of the software we write are "modules" that are written like this:

A boilerplate generator generates a complicated directory structure containing incomprehensible makefiles, configuration files, some files in this program's scripting language, and a bunch of other crap which I will leave out for brevity.

Once the boilerplate is generated, we create a c++ source files, and edit the correct makefile to reflect this, and this is how we can begin to write code. But then we need to write about 100 lines of additional tedious-to-write code into these source files in order to "link" it. It's a real nuisance.

Here are the options I thought of so far to deal with this:

* I thought of a new way of writing these modules, where we use decouple the boilerplate from the useful code. The useful code would be compiled as a shared object library (Linux equivalent of dll), and I would just modify the "module" to load this library. Now I can make multiple shared objects for different purposes, and the "module" will load the shared object at runtime. The pros of this are: I can write libraries with very simple source files, without needing to generate boilerplate every time I make a new module, and without needing to do tedious work to do the linking. The con, which my boss mentioned when I brought this idea up with him, is that it is another layer of misdirection. It can be nice to have all the code in one place without needing to worry about library directories, etc.

* I can write or try to look for a more advanced boilerplate generator that will do the "linking" for me. Pros: It's easy to generate. Cons: it is unaesthetic and you run the risk of losing the script.

* I can just suck it up and make a new module using the boilerplate generator, or by copying an old one, and renaming all the variables.

Should I try to decouple them, or is the misdirection not worth it?

There is something missing in this story.  If you "need to write about 100 lines of additional tedious-to-write code into these source files in order to link it" then how would linking to a shared object library work without such code?  And if there is some way to automate linking then you should be able to automate using C++ files in another directory.  Without fully understanding this, I agree with your boss.  Best to have one executable and figure out how to organize the code to remove the pain.

Maybe "linking" was bad terminology I will explain what I mean:

In order for a class A that we write to be loadable by our system, we have to write this stupid code where we create special objects corresponding to every parameter in the class's constructor, and then we create another object that uses these objects to do something, and we also have to specify the number of arguments, the types of the argument, and the name of the class. And you also have to call a "register" function that takes in a pointer to this object. And somewhere in the process you have to write a function which calls the constructor of Class A, and you have to declare this function as static or it won't work. And then once this is done then you have to edit to a bunch of config files with the names of some of these registration functions that you wrote, or else it won't work.

I have seen someone try to partially automate this before using compiler preprocessor macros. This only works for automating the C++ functions/objects you have to write, not the editing of the config files. I guess I could dig this up and try to include this in my projects, but I would say this is not ideal.

My idea is to bypass all this by keeping class A as a separate shared object. And then if you want to start a second project that involves writing class B, then you just create a shared object of class B, and you can use re-use the tedious code you wrote to load class A, without modifying it or recompiling it. It would be just a single extra line that you add to the startup script.

One drawback of this approach however is that it only works for constructors that share the same number of arguments, and the same types of arguments. In my case, most of the classes I write are derived from the same base class, and have the same number of arguments as it, so it's not really an issue, at least not at the moment.

I also will PM you some real examples of the boilerplate.