Unable to runtime compile with a non-default gcc about runtimecompiledcplusplus

[dougbinks]

Thanks for the input - indeed this one has been bothering me as well.

Adding a general compile command would be a good idea, though I think this separates into two different cases:

1. Compilers with compatible arguments to g++, so the compiler can be re-targeted by simply changing the executable.
2. Compilers which have different arguments.

This is also complicated somewhat by trying to keep the API relatively similar between POSIX and Windows, though I'm happy to allow some differences as obviously the parameters already differ.

Although adding another argument to RunCompile() is a little clumsy since it needs header & source changes for the build and compile classes (with 2 compile classes so far), I don't find this hard to do myself. However a compile context structure seems a good step now these the function parameters have grown this complex.

I can fairly easily do this work the next time I get a bit of free time, which may take a few days or potentially more. If you'd like to undertake it yourself then feel free to go ahead, or let me know if you want guidance.

[kubaroth]

Yes adding another parameter is not ideal here. wrapping compile parameters into a struct seems to be a better option. No problem I can take a look at it in the next few days.

[kubaroth]

I'm interested to find out your opinion about using ProjectSettings instance as the container to pass around compiler settings. The advantage is that it already holds all the compile/link information. Adding new fields is easy too. It can be passed as an argument to BuildTool and RunCompile functions.
There is a down side at the moment too. It is defined as an inner class and is not accessible from other places (BuildTool.h). I've started initially looking at the ways to extract it into it's own class but this seems to be asking for a whole RuntimeObjectSystem overhaul which I don't feel confident to undertake yet.

[RuntimeCompiledCPlusPlus]

It's 1am here and I'm not capable of a decent response, so I'll get back to
you when I am :)

On 13 January 2015 at 23:14, kubaroth [email protected] wrote:

I'm interested to find out your opinion about using ProjectSettings
instance as the container to pass around compiler settings. The advantage
is that it already holds all the compile/link information. Adding new
fields is easy too. It can be passed as an argument to BuildTool and
RunCompile functions.
There is a down side at the moment too. It is defined as an inner class
and is not accessible from other places (BuildTool.h). I've started
initially looking at the ways to extract it into it's own class but this
seems to be asking for a whole RuntimeObjectSystem overhaul which I don't
feel confident to undertake yet.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

[dougbinks]

I think the easiest approach would be to create a new struct, and then use that in the ProjectSettings struct, as this would reduce dependencies.

[kubaroth]

Hey Doug, hope you haven't started working on this issue.
In the next 1-3 days I will have a pull request regarding this issue - it is almost ready. Unfortunalty I don't have an access to Windows so the custom compiler location will support POSIX systems only.

[dougbinks]

Thanks! Sounds good - I can do any work for Windows if needed.

On 22 January 2015 at 08:46, kubaroth [email protected] wrote:

Hey Doug, hope you haven't started working on this issue.
In the next 1-3 days I will have a pull request regarding this issue - it
is almost ready. Unfortunalty I don't have an access to Windows so the
custom compiler location will support POSIX systems only.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

[dougbinks]

Closed via #58