Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Define a public API #7
This commit sets the default visibility to hidden and exports all the symbols required to compile mimic-full.
Some of those symbols should be private, for instance:
This API should little by little be reduced to something well designed and all public functions should be prefixed with
This is needed in order to build mimic in Windows with the msvc compiler
@@ Coverage Diff @@ ## development #7 +/- ## =============================================== + Coverage 17.81% 17.82% +<.01% =============================================== Files 79 80 +1 Lines 8867 8874 +7 =============================================== + Hits 1580 1582 +2 - Misses 7287 7292 +5
We're using the
I see that in two places it is used, so I guess it's necessary sometimes. Is there a good guide somewhere to tell how to determine if the hidden attribute needs to be explicit?
This is the criteria I have tried to follow.
There is quite a bit of information to digest and I am totally open for opinions and clarification, as this is something I have made up from what I have learnt, and there may be mistakes or holes in these rules.
There are some questions and clarifications in the end. If you believe this is overly complex, feel free to say so, it is the best I could come up with to cover all mimic-core use cases.
a) A core executable is an executable compiled by this repository (e.g.
Thanks for any feedback! Even "it's overly complex, I don't like it" would be good!
I understand your reasoning here and it mostly sound sane :)
I do think a MIMIC_CORE_PROTECTED macro would be useful, otherwise I'd be "Hey why is this exposed as a public?", remove it, get failing tests and realize why it was there :)
Regarding MIMIC_CORE_PRIVATE. I guess it will be useful in the beginning at least, might be a hurdle for (possible) new contributor (/lazy swedes) to have to mark new functions. In the least we should see if we can have an automatic test to make sure the code keeps some sort of structure.
I have rebased the pull request to be up to date with the latest commits in development. I have also changed the symbol marks in
Message from the two last commits: