1 |
This week I began to work on implementing support for autotools in my |
2 |
ebuild generator. I am now on schedule. |
3 |
|
4 |
The first thing I did this week was to implement a basic automake parser |
5 |
and I was pleasantly supprised that it was a lot easier to write and |
6 |
interpret than the vanilla make files. |
7 |
But that is probably why automake exists in the first place… |
8 |
|
9 |
I then went on to write a autoconf parser. |
10 |
That didn't went as smoothly as I wanted as you have to be really |
11 |
careful in how you parse the files as you can mix in commands that |
12 |
creates unbalanced parentheses or may screw with your parser in other |
13 |
ways. |
14 |
Thankfully they have quotation marks "[]" that you should wrap around |
15 |
such cases. |
16 |
|
17 |
Now I'm moving on to figure out how I should structure how the |
18 |
program searches for possible useflag and/or optional dependecies. |
19 |
|
20 |
I'm thinking about having it parse the makefile first and look for |
21 |
variables that configure will supply to it in relevant areas. |
22 |
Like variables that pull in stuff from EXTRA_…_SOURCES for example. |
23 |
This way I can look for where those variables are defined in the |
24 |
autoconf file and then just evaluate those parts of the autoconf file. |
25 |
|
26 |
I don't know if this will make it easier or save me any time. But it |
27 |
seems to me like it would be better if I could just evaluate those cases |
28 |
as they use, as far as I've seen, the same autoconf macros/functions. |
29 |
Which would mean that I can narrow down which macros I have to |
30 |
implement. |
31 |
|
32 |
I would really like some feedback on this as it could be a really really |
33 |
bad idea. |