1 |
Recap: |
2 |
The goal of this ebuild generator is to be able to generate ebuilds by |
3 |
only scanning the source of the project. By doing this it should be |
4 |
able to generate ebuilds for projects with somewhat sane build/install |
5 |
systems. |
6 |
|
7 |
This week I've finished the new revision of the makefile parser. So now |
8 |
it should be able to parse much more advanced makefiles than before. |
9 |
Because of this I was able to generate a simple ebuild for the open |
10 |
source web browser uzbl. |
11 |
However I noticed that I need to work some more on my C/C++ parser as it |
12 |
now pulls in some dependecies that shouldn't be there because of #ifs |
13 |
like: |
14 |
#if GTK_CHECK_VERSION… |
15 |
|
16 |
I also noted that uzbl uses a few shell commands in the makefile. So I |
17 |
should perhaps add the packages that the commands belong to that it uses |
18 |
in there (like they have done in the ebuild in portage). |
19 |
Because of possible shell commands in the makefiles I should setup a |
20 |
sandbox or perhaps borrow the "jail" that portage uses so my ebuild |
21 |
generator won't be able to execute malicious shell commands. |
22 |
|
23 |
There is still a lot of missing features in the makefile parser. But as |
24 |
most projects today isn't pure makefile projects I will now move on to |
25 |
support autotools projects. |
26 |
|
27 |
One of the things that causes most problems with makefile parser was the |
28 |
implicit rules and that "magic" that came with that. So I really hope |
29 |
that there is less of that with autotools as I will be able to implement |
30 |
the parser faster if I only have to handle the stuff that is actually |
31 |
written in the files. |