| 1 |
> |
| 2 |
> 4. How to work with gnu autotools. Writing a build system. |
| 3 |
|
| 4 |
Writing a build system from scratch is actually not a requirement. |
| 5 |
However one should understand basics of the most popular build systems |
| 6 |
and probably have some advanced understaning of Makefiles and how flags |
| 7 |
work, where they should be placed and so on which leads me to what you'v |
| 8 |
been missing a bit: |
| 9 |
|
| 10 |
QA |
| 11 |
|
| 12 |
Why we do it and what the most common QA issues are (things like |
| 13 |
disrespected CFLAGS/CC/LDFLAGS, bundled libs, broken parallel make, |
| 14 |
portage QA notices (i.e. broken strict-aliasing), automagic dependencies |
| 15 |
and so on). |
| 16 |
|
| 17 |
That's what seperates us from many other distros. |
| 18 |
|
| 19 |
> |
| 20 |
> 5. How to write ebuilds, ie the dev manual. How to work with cvs and git. |
| 21 |
|
| 22 |
a few more specific thoughts on this... |
| 23 |
|
| 24 |
IMO one of the more important points of writing ebuilds is to figure out |
| 25 |
the dependencies correctly and how to implement use flags properly. |
| 26 |
So figuring out dependencies usually involves reading the build system |
| 27 |
and might even involve grepping/reading source files for includes/dlopen |
| 28 |
or language specific things (note the differences in ruby, perl and |
| 29 |
python...), cause assuming that the information from upstreams |
| 30 |
INSTALL/README file suffices is almost always wrong. |
| 31 |
Regarding useflags it's important to a) decide whether it makes sense to |
| 32 |
offer that useflag/choice at all, b) what name to choose, so we don't |
| 33 |
confuse the user, c) give descriptions in metadata.xml if the usecase |
| 34 |
differs from the global description and d) test them all (which leads us |
| 35 |
to point 6) |
| 36 |
|
| 37 |
And that's exactly how I usually begin writing an ebuild: |
| 38 |
- figure out all dependencies |
| 39 |
- figure out what useflags to provide and how to implement them |
| 40 |
- fix QA issues/patch the build system |
| 41 |
|
| 42 |
Then the next thing is just understanding phase functions and the |
| 43 |
regular helpers like econf/cmake-utils.eclass/eutils.eclass which you |
| 44 |
can read up quite easily. |
| 45 |
|
| 46 |
I would probably leave a few things behind like java ebuilds, ruby |
| 47 |
ebuilds or even python ebuilds (due to the current eclass |
| 48 |
conversion/confusion) and focus on autotools, cmake and plain Makefile |
| 49 |
related things. |
| 50 |
|
| 51 |
Give a few good and bad examples for each of them, so people understand |
| 52 |
that every build system can be messed up. |
Archives