Building Oolite master from GitHub for/by amatures.

[Gimi]

I have been playing around with the GitHub source and building Oolite by:
Using the GitHub Tool for Windows to download the source from GitHub.
Using the "Building Trunk the Easy Way" package put together by Another Commander to build Oolite. (Simply by pointing the compiler at the relevant directory.)

I have a few "amateurish" questions.

First, when building source, a directory called <obj.win.spk> is created. All files within directory (430 in total) are subsequently queued by the GitHub tool to be committed to the project. Should this directory be included in the gitignore file?

Second, how do I select which branch to build, or are the tools provided in AC's package to basic to do that without changing the make file or worse?

[cim]

First, when building source, a directory called <obj.win.spk> is created. All files within directory (430 in total) are subsequently queued by the GitHub tool to be committed to the project. Should this directory be included in the gitignore file?

Yes.

Second, how do I select which branch to build, or are the tools provided in AC's package to basic to do that without changing the make file or worse?

git works slightly differently to svn in this respect. The Github tool should let you choose which branch to check out. If you then want to build a different branch, you need to go back to the tool and check out that branch instead.

[Gimi]

Hmm.

This is not as easy as it seems with my limited understanding of both Git and GNU Step. The shell that comes with AC's package is not aware of what branch is selected in the GitHub tool (obviously), so I would need to use the Git Bash shell to compile. Git Bash shell has no knowledge (path to) of the GNUStep compiler tools provided in AC's package (obviously), so now I need to start configuring. What, I don't yet know.

Time to boot up a VM and play around without messing up my windows installation.

[Cody]

<reads thread - backs away>

[cim]

This is not as easy as it seems with my limited understanding of both Git and GNU Step. The shell that comes with AC's package is not aware of what branch is selected in the GitHub tool (obviously)

I haven't tried it, but it shouldn't need to know. So long as you use Git to check out the branch you want, then go there in AC's packaged shell and compile, it should work. Whether the files being compiled got there via svn or git (or some other method) shouldn't matter to the compiler.

[another_commander]

Gimi, why don't you just use the git shell to do your checkouts and pulls and my package to do the building? No need to must have one tool for everything. At least that's what I do.

When I want to update from git, I do the following:
1. Launch git, switch to the folder where I'm going to pull sources.
2. Execute git pull. If I want to checkout a branch other than master, I do checkout <branchNameGoesHere> first, then pull.
3. Shut down git shell.
4. Launch compiler shell, switch to the folder I just updated, build.

Of course there is a way to do it properly by updating my package to include the git stuff, but my time these days is severely limited, so I find the above way just as good for the moment.

[Gimi]

This is not as easy as it seems with my limited understanding of both Git and GNU Step. The shell that comes with AC's package is not aware of what branch is selected in the GitHub tool (obviously)

I haven't tried it, but it shouldn't need to know. So long as you use Git to check out the branch you want, then go there in AC's packaged shell and compile, it should work. Whether the files being compiled got there via svn or git (or some other method) shouldn't matter to the compiler.

I suspect that the Windows GitHub tool works slightly different from the command line tool. When I check out something it downloads the whole repository. Branch is selected by drop down menu in the tool. I can then choose to open a shell within a specific branch. The shell is aware of what branch it's working in, but I have no idea how that works when I compile.

So the shortest way to the target seems to be to use Git command line, but I was hoping for a simple solution.
Another option may be to use the Git shell to compile, but I don't know if the shell's knowledge of what branch is selected is carried over to the compiler. (If not, the whole tool seems kind of pointless.)

[Gimi]

Gimi, why don't you just use the git shell to do your checkouts and pulls and my package to do the building? No need to must have one tool for everything. At least that's what I do.

When I want to update from git, I do the following:
1. Launch git, switch to the folder where I'm going to pull sources.
2. Execute git pull. If I want to checkout a branch other than master, I do checkout <branchNameGoesHere> first, then pull.
3. Shut down git shell.
4. Launch compiler shell, switch to the folder I just updated, build.

Of course there is a way to do it properly by updating my package to include the git stuff, but my time these days is severely limited, so I find the above way just as good for the moment.

I was kind of hoping to use the Windows GitHub tool. So I have been experimenting with that. Using the Git shell and downloading each branch to a separate folder as you describe seems to be the best option.

[another_commander]

No need to download branches to different folders. You only need to do checkout branch then pull. Once a branch checkout is complete, the folder structure of your local repository mirrors that of the selected branch. When you want to return to master, just do a checkout master. Again, the folder structure will return to mirror the master structure. It's that easy really.

[Gimi]

No need to download branches to different folders. You only need to do checkout branch then pull. Once a branch checkout is complete, the folder structure of your local repository mirrors that of the selected branch. When you want to return to master, just do a checkout master. Again, the folder structure will return to mirror the master structure. It's that easy really.

Really?
Then I should be able to use the Windows tool anyway.
Select branch in the tool, do a sync, and then compile.
How can I make Oolite display what branch/version I have compiled? The log displays 1.77.1 regardless I think (I'm reinstalling a few things, so can't check for sure just yet).

[cim]

Ah - looks like we haven't got around to updating the version number in master yet. That should be fixed now.

[Gimi]

Thank you again cim. Was not my intention to trigger all this work.
Will be testing using the tool and if it works I'll put in a short "how to" in the first post in this thread.
Will keep us simple minded people from installing and using Git command line if it works.

[Thargoid]

Speaking as an interested idiot, what windows client are you using? I may give this a run-out later if I have time, but there seem to be a few client options about, with varying and mixed reviews. A good recommendation could save some time here. Also that promised guide sounds interesting

[Cody]

Gimi simple-minded? Thargoid an idiot? Oh dear... where does that put me?

[Gimi]

Speaking as an interested idiot, what windows client are you using? I may give this a run-out later if I have time, but there seem to be a few client options about, with varying and mixed reviews. A good recommendation could save some time here. Also that promised guide sounds interesting

Have been trying to keep it as simple as possible.
So far so good, I have been able to compile both 1.77.1 Maintenance and 1.79 Master with no errors.
The tool I'm using is the GitHub native client for windows. It's just a basic GUI pulled over a subset of the full Git installation.
I have replaced the default Shell in the client with the shell from AC's package in Options. That seems to work.
I have also updated .gitignore so that the commit requests don't pop up all the time.

I can now switch between branches in the tool, but I have to do a full compile each time I switch.
I still need to check if there are any adverse effects from switching between branches. I suspect that I should issue one of those clean up commands, but from what I understand that is an SVN command, so not sure how that is going to work. Still might be better to just use the Git CLI. More exploring this evening.