STB-Style Library Integration

[rationalcoder]

Context

At work, we use an old VCS (ClearCase) and git, and we support x86 Linux, x86_64 Linux, and various embedded GCC ARMv5 toolchains. This means dealing with different compiler versions, standard library versions, different configuration requirements (strict alignment on ARM, for example), etc.

I have been introducing easy_profiler, but it is getting to be a huge pain. After every new version of this library, I have to create a new branch, run a bunch of CMake scripts, build static and shared library versions for all of our targets, and try to get that branch merged in and visible by everyone else on the team.

Request

I would like to see an option for easy_profiler_core that is similar to the STB libraries (https://github.com/nothings/stb) that can be used instead of CMake.

That is, I want to have the usage code be the same as it is now, except I want to be able to create a separate, per-project easy_profiler.cpp that I can commit to version control and link directly with my applications. Such a file would contain something along the lines of:

#define EASY_CORE_IMPLEMENTATION
#include <easy/profiler.h>

Care would then need to be taken to make sure that clients know what #defines to use for configuration , but this could be accomplished with one extra example file in the source tree that has a file like the one above with a list of all current #defines that the project respects.

Then, if I didn't want to define easy profiler stuff in my build system, I could create another file, easy_profiler.h, that defines everything the project wants before including easy/profiler.h.

My project's easy profiler source files would then look something like this: easy_profiler.h:

#define EASY_ENABLE_ALIGNMENT
#define EASY_ENABLE_STRICT_ALIGNMENT
...
#include <easy/profiler.h>

easy_profiler.cpp:

#define EASY_CORE_IMPLEMENTATION
#include "easy_profiler.h"

and the rest of my project files would just #include "easy_profiler.h". Even having to do things like potentially compiling easy_profiler.cpp separately in my build system with high optimization flags is preferable to what I have to do now.

Implementation

To accomplish this, I imagine you could just do something at the end of easy/profiler.h that #ifdefss on EASY_CORE_IMPLEMENTATION and #includes all of the easy_profiler_core source files. This is an easy thing to do, and it would be so much better that I will do it myself, if I have to.

Future

My final goal is have just easy_profiler_core in my project's source tree. As a future goal, it would then be nice to just run some script, maybe easy_upgrade.sh, that will pull from the latest release, remove everything that isn't easy_profiler_core, and overwrite the current files. I could then checkout the #defines change-log and update my custom files accordingly, but let's not get ahead of ourselves.

[rokups]

Migrating to such source storage model makes it awfully inconvenient to further work on such code. It instantly kills all the helpful IDE features like syntax highlighting and code completion.

There are few options to achieve something similar.

• Amalgamated builds
• Including source files in header

But never ever this library should be converted to annoying single lump of code that stb is.

[rationalcoder]

@rokups I'm not sure what you mean. It doesn't kill any IDE features and makes the code considerably easier to work with. Also, I am not asking for a conversion of any kind. Your usage of easy_profiler would be left unchanged...

Are you talking about further development of the library, and having IDE features broken when working on it? Maybe you thought I meant literally pasting the source files into easy_profiler.h? Your second example is pretty much what I am asking for... the STB libraries only literally past the source code because they are very single purpose, and the trade-off of developer convenience for client convenience makes more sense. For easy_profiler_core, it doesn't make sense, but #includeing the source files in there as an option does and provides most of the client convenience.

[cas4ey]

Hi @rationalcoder

If you already done this for your project, may I ask you to share sources (if it's not a part of NDA)?
Or at least some example. If it's ok then I could update them in the future when/if new sources would be added.

One reason of building easy_profiler as separate library is that it creates a singleton ProfileManager, so including it's sources into several libraries in your project will make it to create new ProfileManager instance for each library it was included to.

[rationalcoder]

That's a good point. Maybe that's just a downside that someone accepts if they decide to use the easy (STB) integration version? I can tell you from experience that, if someone wants to use this feature because building new library versions is a pain, then they will likely be including other libraries that they care about putting profiling blocks into in a similar fashion.

For example, at work we link to things like boost (unfortunately), but we don't care about putting blocks in it. Putting blocks around the calling code is enough. For our "common" libraries, I drop a common.cpp in the source directory of our project that #includes the common headers with a #define EFJ_COMMON_IMPLEMENTATION. If you are building separate libraries for everything, and you want to put profiling blocks in them, you are probably in an environment in which building new library versions is pretty easy (like Win32), and you can just use the CMake version.

Unfortunately, I haven't gotten around to implementing it at work (we are just kind of stuck at 1.3.0). I can, however, come up with an example if you are unclear on some part of it.

[cas4ey]

Well, I just want to warn you that if you will try to include profiler in such manner to several libraries and link them into one project then this would not work (at least network part). Just warning.

I think it would be easy to update an stb version additionally to the main version.
But an example will help. :-)