| 1 |
On 22:08 Sun 03 Jul , darkdefende@×××××.com wrote: |
| 2 |
> Now I'm moving on to figure out how I should structure how the program |
| 3 |
> searches for possible useflag and/or optional dependecies. |
| 4 |
> |
| 5 |
> I'm thinking about having it parse the makefile first and look for |
| 6 |
> variables that configure will supply to it in relevant areas. Like |
| 7 |
> variables that pull in stuff from EXTRA_…_SOURCES for example. This |
| 8 |
> way I can look for where those variables are defined in the autoconf |
| 9 |
> file and then just evaluate those parts of the autoconf file. |
| 10 |
> |
| 11 |
> I don't know if this will make it easier or save me any time. But it |
| 12 |
> seems to me like it would be better if I could just evaluate those |
| 13 |
> cases as they use, as far as I've seen, the same autoconf |
| 14 |
> macros/functions. Which would mean that I can narrow down which macros |
| 15 |
> I have to implement. |
| 16 |
|
| 17 |
I wouldn't do it that way; I would complete ignore the Makefiles on an |
| 18 |
autotools project, since as you've said they are fraught with |
| 19 |
complexity. Generated Makefiles are far more complex than handwritten |
| 20 |
ones, although the nice thing is that if one works, they all do. |
| 21 |
|
| 22 |
I would check AC_ARG_WITH and AC_ARG_ENABLE, which tells you what |
| 23 |
features are truly optional and also give a good idea of what the USE |
| 24 |
flags should be. I'd use those to determine what variables and defines |
| 25 |
get set in an optional way, and then track them through (1) Makefile.am |
| 26 |
files to see how it changes what's built and how and (2) the source |
| 27 |
files themselves to see how it changes #ifdefs and thus what's included. |
| 28 |
|
| 29 |
-- |
| 30 |
Thanks, |
| 31 |
Donnie |
| 32 |
|
| 33 |
Donnie Berkholz |
| 34 |
Admin, Summer of Code |
| 35 |
Gentoo Linux and X.Org |
| 36 |
Blog: http://dberkholz.com |
Archives