Howto:Build and run FlightGear on Raspberry Pi 4: Difference between revisions

Jump to navigation Jump to search
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]]
320

edits

Navigation menu