[rmkit] multiply-defined symbols in a multi-file c++ project about rmkit HOT 6 CLOSED

it's more than just include guards, it has to do with .cpy and how it generates code.

currently, .cpy only generates .cpp code (and no header files). we've worked on adding a way for cpy to generate .h and .cpp files, but it's not finished yet.

i recommend using QT for a better build experience: it has emulator, build guards, etc.

from rmkit.

Maybe just need some include guards?

from rmkit.

I might give Qt a shot, although what I'm doing isn't too complicated, and I appreciate how straightforward rmkit for what I'm doing (mostly just drawing on a canvas plus a couple buttons). At this point adding a separate make step to combine all my source files into one is producing pretty reasonable compile times 🤷

from rmkit.

the biggest annoyance with okp for me is inability to generate .h and .cpp files. for even relatively simple cpp (namespaces, templates, nested classes), its hard to auto generate a header file. there is makeheaders from fossil, but it doesn't support namespace/template keywords. the best thing i've seen so far is doxygen's extractor, but it generates XML data.

the reason i want to split .h and .cpp is because i'd like compile times to significantly go down, and i'd like people to be able to include rmkit.h multiple times from multiple files.

in c++20, there is the module standard, which i think would fix my issue with generating .h and .cpp files. but in general, i don't like using new language features unless necessary.

the other route i've thought about is a new language with a formal grammar and parser, s.t. generating the header and implementation files will be possible. without an easier grammar, okp has to support arbitrary c++ which is tough to parse properly.

writing a new grammar / syntax is not something i'm really interested in, though, so i feel that waiting out the c++ module support (and adding it into okp) is reasonable

from rmkit.

i've been revisiting this. in august last year, we experimented with a "@hidden" (or "@impl") flag in okp which can be used to separate a function into its header and cpp file. Last week, I picked up development on that branch of okp and pushed it along some more. There are 3 major cases where the "@hidden" keyword was initially necessary:

• in front of headers only applicable to a .cpp file (@hidden #include "foo.h")
• on non inline/non static methods at the namespace scope
• on static variable initialization

of these, only the static variable definition is a real problem for rmkit. we can use inline and static to decorate functions (as mentioned in original post by mrichards42). the major additional feature added to okp was the ability to spot lines like static int foo = 1 and separate it into two pieces: one for the .h and one for the impl.

i've pushed an example of using rmkit.h in this new way to https://github.com/rmkit-dev/rmkit-cpp-example. notice that rmkit.h gets compiled to a .o file (with its impl) and then linked against the other .o files.

from rmkit.

closing out, since i think this is fixed

from rmkit.