On 12/17/2012 01:11 PM, Maxim Kammerer wrote:
On Mon, Dec 17, 2012 at 5:32 PM, Anthony G. Basile<bluen...@gentoo.org> wrote:
Please comment. If it gets systematized enough, it can be a guide to future
devs too.
Hi, what is the level of the students, what are the prerequisites
(i.e., have they already seen some systems programming using C?), and
how many weekly hours? Have you already designed some assignments? I
can think of the following:
1. Create a small makefile-based project with a separate shared
library, an executable, and a man page. Determine run-time and
build-time dependencies. Then convert to autotools, update
dependencies. Do it all on GitHub, with a separate branch for
converting to autotools.
Its a second year course so they've had some programming in Java but no
serious C. It meets 3 hours a week but I expect about 6 hours more per
week in assignments.
There is some overlap with other stuff I've taught: Makefiles,
autotools, git and shared objects. I did my lecture materials in git
and then ran a git rebase -i in class and redid the commits showing them
what happened on each point. You can see some of that stuff here ->
practice with git ->
http://tweedledum.dyc.edu/gitweb/?p=model-git.git;a=summary
how autotools works ->
http://tweedledum.dyc.edu/gitweb/?p=autotools.git;a=summary
how Makefiles work ->
http://tweedledum.dyc.edu/gitweb/?p=makefile.git;a=summary
how shared objects work ->
http://tweedledum.dyc.edu/gitweb/?p=shared-objects.git;a=summary
2. Write an ebuild for the project above, maintained in an overlay
(also on GitHub), with sources fetched from GitHub. Add some small
patch to configure.ac in the ebuild. Add USE flags. Add "make check"
support to the build system, test with FEATURES=test. Many
ebuild-related tasks can be easily added (e.g. installing init.d
scripts).
This would be totally new to them but I agree that's a good idea. I
don't know about GitHub. Can you delete projects from it when you're
done because I don't want to polute GitHub with lots of unpolished stuff.
3. Take an old-version ebuild for a project with a known bug, fetch
the relevant git tag, and bisect to find the bug. Prepare a patch,
describe patch submission process.
Hmm ... I didn't think of this but I could do that with the kernel on
virtual machines.
Wrt. subjects covered, will you cover sandboxing, installing to image
vs. merging to live system, etc.? I would expect students to like such
stuff.
At some point I would have to cover that. Like when I got over the
phases of emerging, stepping through them with ebuild.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
