320
edits
Line 582: | Line 582: | ||
==Compiling == | ==Compiling == | ||
===When to recompile/build=== | |||
Edward wrote: | |||
<blockquote> | |||
There are a number of ways to follow this: | |||
- Watch for release announcements [1]. These announcements | |||
correspond to the git tags for the releases, not the git release | |||
branches. | |||
- Subscribe to the flightgear-commitlogs mailing list [2]. You | |||
will receive one email per commit on all the FG repositories, so it is | |||
a little noisy, but you'll see when releases are branched and when | |||
they are tagged. | |||
- Follow this list for messages from James as to when he creates a | |||
new release branch. This will be the initial branch that commits are | |||
cherry-picked to, and tags made for different release revision | |||
numbers. | |||
- Go completely nerdy and write a very complex cron job script to | |||
email you when specific remote repository events occur (not | |||
recommended, as email filtering of the flightgear-commitlogs messages | |||
is easier). This is risky because if you accidentally poll SF too | |||
quickly, they will permanently IP blacklist you. | |||
If you are interested in development, you absolutely should be making | |||
changes based on the 'next' branch. You should also develop by | |||
committing changes to branches on your local repository - not by using | |||
stashing or git-worktree. You can use 'git rebase -i next' (after | |||
merging 'origin/next' to your local 'next') to pick up your branch | |||
point and shift it to the latest code. Or just delete the branch with | |||
'git branch -D [branch_name]'. Don't be afraid to have lots of | |||
local-only branches. It is a good way, and the correct VCS (version | |||
control systems) way, to organise your coding. I have 30 untracked | |||
branches for my flightgear clone, 19 for simgear, and 2 for fgdata. I | |||
highly recommend not touching git-worktree, as that is not how | |||
developers normally use git! This tool has a specific purpose - for | |||
example fast switching to maintain, build, and release new revisions | |||
for ancient long-term releases - but this purpose is not what | |||
developers use for normal development. And with the CMake build | |||
system git-worktree is partly redundant as you just create different | |||
'build' directories for the different releases. | |||
Anyway, for normal VCS development just use lots of local repository | |||
branches. You can then push interesting ones you would like backed up | |||
to your remote fork. | |||
Regards, | |||
Edward | |||
</blockquote> | |||
===Download_and_compile.sh=== | ===Download_and_compile.sh=== | ||
[[Scripted Compilation on Linux Debian/Ubuntu]] | [[Scripted Compilation on Linux Debian/Ubuntu]] |
edits