Development virtual machine

[Licho]

It would be cool to have virtualbox image with all the stuff ready to develop engine (building, git etc).

Atm biggest obstacle is setting up developer environment.

I installed ubuntu virtual machine on springrts.com, if someone is interested setting up environment, let me know.

Users could then simply download image (or rsync it to keep it up to date).

[koshi]

but for ubuntu?? that's just a apt-get build-dep spring and git-core away
for windows I would totally agree, but that's not something you could really pass around then

[Licho]

Is it? How would i know - im linux nub, i want to open machine and click "develop here"
and then "submit changes here"

I don't even know what IDE should I use :)

[hoijui]

what would it need...
(apart from hte obvious like git, cmake, deps, ...)

IDE (at least one):

• Code::Blocks
• KDevelop
• QTCreator
• NetBeans
• Eclipse

graphical diff viewer:

• meld

A few links on the desktop, and a dedicated "Spring Development" "Start"-Menu folder, containing:

• link to IDE
• link to gitk
• link to git gui
• link to console + cd spring-source-dir (in case some dev tells the noob to execute git commands or whatever)
• link to GUI file-system browser + cd spring-source-dir
• get changes from remote (latest unstable)
• delete my changes
• try to update to remote (git stash, git rebase, git stash apply?)
• link to git-noob-help page
• github stuff (user should create a fork and put changes there)

i guess at first, we should really only care for native linux dev for noobs. cross-compiling can still be added later (that is the messy part).
The optimum solution would probably be, to have a dedicated virtualBox image with a cross-compile bot (no X required). That could then be maintained by the community, and used practically everywhere: buildbot, build-slaves, devs, noob devs (add an easy way to use it from the noob-dev-env image).

[koshi]

How about putting the links, extra dependencies (ide, git,tools), maybe docs, into a (set of) packages. This way it would be useful for new people who don't want to run their dev env inside a vm and users of the vm image both.

Edit: when I say put deps into, I mean make a meta package that depends on them

[Licho]

Its for windows users ffs. Windows users don't go around 10 links just to do stuff..

Whole point of it is so you don't have to waste hours setting it up.

You know how you start developing zero-k lobby?

You download visual studio express, download sources, open it and it works. No hassle, no third party libs to download etc.

But even this is annoying - you need visual studio and svn. We even considered virtual machine for this :)

[AF]

Surely somebody can write an automated tool to download the spring sources ( and use cmake to generate the necessary parts that arent included ), put it in a folder, extract the VS Dependencies into the right folder, and archive it all up again for download, same with mingwlibs.

Saving time and effort is paramount. Even if they end up loading visual studio first time, they might fix one or two compile bugs to get it working and add extra features which can then be brought into the fold. Im sure academia and projects that don't actively post here would love it if with did this.

The main obstacle I see is that there is no personal need for any of us to do it. We have our build environments, and we have official policy. I dont think that needs to change for this. We have a flotilla of linux developers, lets not interfere with how development here occurs, theyre figuring that out for themselves. Lets just provide a low maintenance alternative for other people. We already have nonofficial support for visual studio anyway (engine developers who use it, not a lot of them, but enough, we can just add a warning that it was provided out of the goodness of our hearts but with no promises )

If someone builds this tool for release versions of spring, would it be allowed it on the download page (or even on the github downloads alongside vanilla source tarballs?).

[hoijui]

@koshi
i guess that makes sense, but would not be enough for linux noobs.

@Licho
the market segment you would target with the ZeroK dev VM, are people that:

• know about virtual machines, how to operate them and have the right software already installed or are willing to do so and have a reasonably fast connection and are willing to download a VM image of a few GB, plus
• do not have an IDE installed, and are too lazy or incompetent to install one, plus
• are competent enough to understand your code and write patches for it

apart of these properties being quite innormal to come together in a single person, i guess it would also be illegal (windows license).

the spring dev VM would target users that:

• use windows (and linux not), plus
• fail to compile spring under windows MinGW, plus
• are reasonable competent in C++, plus
• are willing to operate a VM, plus
• have good enough hardware to run spring on a linux VM (for validation purposes)

the last point could be eliminated if we could incorporate cross-compilation reliably.
This list has the potential to include some people, i would say. 3 (partial) AI devs come to mind, for example.

[Licho]

Well you would sure get at least 2 extra coders - me and quantum.
But if you think that there is excess of skilled engine devs, ok :)


For us lack of easy environment is major obstacle.

It takes just minutes to find and fix problem in code. But it would take me days to setup environment and learn all stuff I need..

Like what IDE to use, how to operate git, how to setup mingw, to download all stuff I need, how to test it after its built etc..

Downloading and running virtual machine is one step and its pretty trivial.

Its self contained environment that wont pollute your system. Even mono does that.

[Argh]

I agree with the above. The last time I bothered with setting up a development environment, it took 4 days and lots of Q&A here, and I didn't want to do anything serious except for write a simple patch

So 4 days, had to keep SVN running in the background, etc., huge wait for initial update from git, etc., all of which are major hassles, plus certain parts of the codebase aren't being kept up to snuff in terms of commenting, it all adds up.

[CarRepairer]

+1 to all this.

I would love to help with engine dev too. I tried to compile in VS and failed (even jK helped me briefly).

I'm a Windows user. I am familiar with using command line Linux in VirtualBox. I know C++. I just want to tinker and learn the engine, but it didn't happen and I don't want to spend weeks just for the setup.

[hoijui]

what none of you made clear is, would you use it if you could only create linux binaries, and had to test the resulting spring binary in the VM?
That would be easy, and i can set that up.

for the cross-compiling, i really would suggest having an other VM with just that, which could be used from this dev VM in turn. if it would be used by all/some devs, and maybe the build-bot too, it would also be make it realistic that it would be maintained.

[Licho]

Well of course having windows executable is preferable, spring runs under VirtualBox but slowly.

But I would use it even if i could not run it. Its enough if i can easily compile and submit changes. Just not for anything bigger.

Why would crosscompiling need separate VM? Cant it be part of this one?

[hoijui]

because maintaining cross-compilation in a working state is ugly work and time intensive. nobody would do that for this VM (thats what i tired to say in my last post).
Not all ways to go have an imminent, technical only explanation, and still they are sometimes the best ones, or the only ones that make sense.

[Licho]

If its so complex and has to be maintained for buildbot already, then buildbot could be used to make executable for people who need to test changes under windows, right?

There is also alternative of fixing building for VS - people who compile VS would not sync but they could at least test or even test against each other.

But I suspect thats harder.

[hoijui]

for you that would probably be an option, but not in general.

in general:
we can not give build-bot usage allowance to everyone that might someday write a patch. (could be) too much load for the server, whether used normally or abused. same applies for making access to it public of course. it would also add an ugly hurdle for potential patch makers again, if they first had to request build-bot access (they also had to know that they need that first), and how to verify them?

even if this was not a problem, there still would have to be quite some changes in the build-bot.

in practice it would also be harder to get to a windows build, then when using a build slave in a separate VM directly (once it is setup).

the only disadvantage the build-slave VM approach has, is that it has to be setup once, initially (that is already done on the build-bot/-slave). everything else would be equal or better.

[AF]

What about my idea of autopackaging everything up into a download with the source, a game folder with a barebones spring install, and required dependencies? Surely at that point all one would need is the compiler, which if done for visual studio would be a matter of just installing visual studio if it isnt already there. Its also easier to implement

[Licho]

Well if it can be made compilable for VS -with just one zip: unzip, open in VS, hit F5 to compile and run - then such solution is superior to even VM.

People could use fairly powerful IDE and debugging tools they are already familiar with then.

[koshi]

Didn't lurker have a self contained mingw env ready for distribution that was capable of compiling spring and had all kinds of tools included?

[Licho]

If it was mingw based, I tried it once but but could not understand it well enough.

Its been 13 years since i was last time forced to compile C on commandline..

Build does not have to sync, but it should be easy to compile and debug in powerful IDE. Im not sure how devving on linux works, do you use some IDE, where you can graphically set breakpoints, watch variables and modify code on the run? Or do people just use gdb like 25 years ago.