Hey, I'm on a roll, so why not another release candidate?
It turns out Lua bytecode isn't as portable as I had supposed it to be, so I am now embedding the actual scripts into the release build, rather than precompiled bytecodes. I found some additional testing machines and have now tried it against both 32- and 64-bit x86 architectures as well as 32-bit PowerPC. Because the scripts are now interpreted at runtime it should work everywhere. Of course, let me know if you have problems.
- Embed scripts instead of bytecodes to avoid portability issues
- solution() and project() now only set the active object when called with a name; remains unchanged otherwise
Please give it a try and let me know what you think. With any luck, this is (really) the last release candidate, but your testing is appreciated.
Thanks, and enjoy!
Share
Hi!
I tried the rc4 out but ran into a little bug I think.
We have separated the solution and project-definitions into separate files in order to use dofile("project.lua") in each solution definition file since we want to include some of our projects in more than one solution file. First time I did a dofile it all went well and generated the solution and project alright. When I did the dofile the second time in another solution file it seem to add the source-files to the first project generated and not regenerating the project.
Is there a include-already-existing-project-into-solution function in premake 4 that I should use instead of my method where I'm regenerating the project in order to get it included in two different solutions?
Regards
Björn
In my simple tests I was not able to reproduce this problem. I was able to dofile() a project into two different solutions, and everything generated and built as expected. Can you post this to the bug tracker, along with a simple script that demonstrates the problem? I'll take a look at it ASAP. Thanks!
Sorry, it was an error in my scripts. Sorry for the inconvenience.