1 |
Hello, |
2 |
|
3 |
So a long time ago solar wrote a bashrc for portage, and posted it on |
4 |
this mailing list for everyone to see. I took it, and started extending |
5 |
it with various things of my own design, and some contributions from |
6 |
others. I've since updated it with the things solar's been adding to |
7 |
his bashrc, plus adding the functionality from ChrisWhites bashrc. |
8 |
Well, adding all of that stuff made the bashrc quite large. In addition |
9 |
I was using CVS for a while, and wrote a lot of hooks to work with CVS, |
10 |
when I went back to 2.0.51, I didnt want to lose all of those, so I |
11 |
backported in a way the hooks from CVS (I mean in a way because the post |
12 |
hooks arent really post hooks, they just run before the pre hook of the |
13 |
next phase), but that meant the bashrc was huge. |
14 |
|
15 |
So, sometime last night or this morning I set out to create a modular |
16 |
portage bashrc [1], and I have done so. I'll admit, the code is ugly, |
17 |
and it probably could've been done better. But it does lay a good |
18 |
framework for future extensions. |
19 |
|
20 |
The bashrc file is just a skeleton that loads the modules, and handles |
21 |
the pseudo-hook implementation. The real magic happens in the |
22 |
bashrc-modules subdirectory. core-functions.bmod contains the basic |
23 |
functions and handles loading other modules. hooks.bmod defines the |
24 |
hooks used and defines functions used to add new function calls to the |
25 |
hooks. The other bmod files define some sort of library for other |
26 |
modules (like an eclass) or functions that get loaded into the hooks. I |
27 |
don't have any documentation written up for that, so read through the |
28 |
source and you should get an idea of how it all works. |
29 |
|
30 |
The BASHRC_DYN_MODULES variable can be defined in make.conf to limit the |
31 |
modules that are loaded by the bashrc. This is useful if you only want |
32 |
to use a subset of the functionality available in the modules, and dont |
33 |
want to load them all. The default behavior is to load all of the |
34 |
modules under ${ROOT}/etc/portage/bashrc-modules/. To extend the |
35 |
bashrc, for example, to add another feature, you simply create a new |
36 |
bmod following the examples given, then either let it load automatically |
37 |
or add it to BASHRC_DYN_MODULES. |
38 |
|
39 |
I've done some thorough testing and beu did some testing as well, so |
40 |
there shouldnt be any major bugs, but if you find some, please e-mail me |
41 |
with them. I'm especially interested in command not found errors. This |
42 |
is some really ugly bash code, so if you run into obscure errors, dont |
43 |
freak out, theyre a result of how I deal with the infrastructure. |
44 |
Overall though, it appears to be stable, and I'm currently using it on |
45 |
my system. |
46 |
|
47 |
Finally, I'd like to thank the people who directly or indirectly helped |
48 |
with this bashrc and the bashrc system: solar, ChrisWhite, beu, |
49 |
bluefoxicy, and anyone else who I forgot to name. Enjoy everyone! |
50 |
|
51 |
Mike Tindal |
52 |
|
53 |
PS: Heed the warning given in the setup phase, you *cannot* modify |
54 |
variables that affect depends because the environment the bashrc |
55 |
modifies isnt picked up by depends. Be very careful with what you do |
56 |
with category.use, since that can very easily break builds. |
57 |
|
58 |
[1] |
59 |
http://dev.gentoo.org/~urilith/portage-tools/bashrc-2.0.51-modular-20050612.tar.bz2 |
60 |
|
61 |
I've got some sample files in that dir for the random files the bashrc |
62 |
supports. |