Define preprocessor declarations and libraries

[Julien Guertault]

Hello,

One issue I had when first plugging RCC++ into my project was that recompilation would fail due to differences between the project compilation settings and the ones used by RCC++: preprocessor declarations and linked libraries.

From what I see, the API exposes a way to declare additional include paths and library search paths, but not other typical compilation options. I managed to get dynamic compilation to work by directly altering Compiler_PlatformWindows.cpp, but this is obviously a temporary hack. As a second step, implementing for example IRuntimeObjectSystem::AddPreprocessorDefinition() and IRuntimeObjectSystem::AddLibrary() looks easy enough, but this still doesn't feel quite right.

If the code defines its own compilation options, that's two sets of options to maintain, and sooner or later they will conflict in one way or another. Moreover, chasing after all existing compiler options sounds like API bloat. I suppose the ideal would be to retrieve the original compilation settings for each file, but that doesn't look trivial.

So I am curious to hear what are your thoughts on the topic. Do you already have a solution maybe?

Regards,

[Doug Binks]

The current set of functions for controlling compile and link options are these in IRuntimeObjectSystem

Libraries can be handled in a semi automatic way, see this documentation libraries on the wiki.

Further documentation on include directories and compile and link options is available - there's no Get for these currently (I manage these internally myself in my own code), but this could be added if needed (submit a github issue request).

For defines, the syntax differs between compilers so adding an interface to handle these specifically could be of interest, along with a macro such as 

#define RCCPP_SETIFDEFINED( x, projectID ) \

#if defined( x ) \

  rccpp->AddDefine( x, projectID  );

#endif

The current approach is more designed for people who use a build tool and can keep a list of project options as a string in some file then load & set that.

Let me know your thoughts - the current API is designed to be thin but this adding defines seems a reasonable extension rather than API bloat.

[Julien Guertault]

Hi,

On Wednesday, December 23, 2015 at 11:14:50 PM UTC+9, Doug Binks wrote:

The current set of functions for controlling compile and link options are these in IRuntimeObjectSystem

Libraries can be handled in a semi automatic way, see this documentation libraries on the wiki.

Further documentation on include directories and compile and link options is available - there's no Get for these currently (I manage these internally myself in my own code), but this could be added if needed (submit a github issue request).

Oh, I had somehow managed to miss those pages and IRuntimeObjectSystem::SetAdditionalCompileOptions() in particular.
 

For defines, the syntax differs between compilers so adding an interface to handle these specifically could be of interest, along with a macro such as 

#define RCCPP_SETIFDEFINED( x, projectID ) \

#if defined( x ) \

  rccpp->AddDefine( x, projectID  );

#endif

I'm not sure about the macro. You may want to define a value, for example _HAS_EXCEPTIONS=0 to alter the STL's behavior.

But then again, chances are we want a different set of definitions depending on the platform anyway. So while such an API function is a nice to have, it looks like for serious multi-platform development loading the compiler options from outside and passing them directly is a better solution.

 

The current approach is more designed for people who use a build tool and can keep a list of project options as a string in some file then load & set that.

Yes, this is clearly the right thing to do. My bad for missing that.

Even better if this can be set per file, which I assume is exactly what projectId_ is meant for.
I suppose we probably also want the compilerOptions_.compileOptions to be concatenated as late as possible, to allow overriding previous command line options. This is only a thought though; I don't have this need.

Thanks a lot for your prompt answers, and have great end of year celebrations.

Keep it up the good work; a tool like RCC++ is a clear a game changer.

Regards,

[Doug Binks]

ProjectIds can be set per class (so per file) or per module (thus per exe/dll/.so). The original use-case was multiple dlls with mutually exclusive compile settings.

Note that compile options are not concatenated, each project is compiled separately.

The macro could be easily extended to set to be the actual define to be what it's currently set to, but if you're happy with the current API then that's great.