| 1 |
On 21:14 Mon 18 Jul , darkdefende@×××××.com wrote: |
| 2 |
> However it didn't go as smoothly as I planned so this is still not |
| 3 |
> done. The main problem is that I need to know what the "switches" in |
| 4 |
> the configure script does so I can link them to useflags with correct |
| 5 |
> deps. If I just were to write a autoconf replacement in python there |
| 6 |
> wouldn't be much of a problem as I just have to "do" not try to guess |
| 7 |
> what it does. |
| 8 |
> |
| 9 |
> Right now I have problems with figuring out how I should handle stuff in |
| 10 |
> the autoconf file that checks for headers,libs or package checks. |
| 11 |
> Granted, in most cases they are just there to see if you have the |
| 12 |
> dependecy or if you have the correct version. |
| 13 |
> So basicly you offen check if the correct dependecy is installed on the |
| 14 |
> system and then give green light to build some extra features. |
| 15 |
> |
| 16 |
> Because my ebuild generator should be able generate ebuilds without all |
| 17 |
> the required dependencies this is a problem. |
| 18 |
> I can't run the checks as they will fail as everything required to build |
| 19 |
> the program might not be installed. And if I skip the checks there might |
| 20 |
> be problems as I can't think of a way that I can guess what it will try |
| 21 |
> to do. |
| 22 |
> |
| 23 |
> Do you guy have any ideas how I should solve this problem? Or should I |
| 24 |
> just "bindly" skip the checks and do what it would do if that check |
| 25 |
> would have passed? |
| 26 |
|
| 27 |
Let me see if I understand this. Autoconf files are basically a mixture |
| 28 |
of m4 and shell syntax. You've discovered that to get all the |
| 29 |
conditionals right, you need to write a shell parser, or somehow run the |
| 30 |
code rather than parsing it to get the result, or punt on the problem. |
| 31 |
|
| 32 |
Here are some ways you could do those things: |
| 33 |
|
| 34 |
Option 1. (Write a parser) See libbash. Not sure how it will work with |
| 35 |
the m4 mixed in, you might need to run autoconf and check the generated |
| 36 |
configure script instead. |
| 37 |
|
| 38 |
Option 2a. (Run the code) Save code until you get to some variable/macro |
| 39 |
you recognize is important because it's used during the build (e.g. |
| 40 |
LIBS, *_LIBS), then run everything around it. It may also be useful to |
| 41 |
notice when files are mentioned and save a separate list of them. You |
| 42 |
might need to trap file access, e.g. using Alex's script for dependency |
| 43 |
discovery. |
| 44 |
|
| 45 |
Option 3. (Punt) Pretend everything is mandatory. Don't handle USE flags |
| 46 |
at all, just put everything as a required dependency. Or, you could |
| 47 |
notice that a feature is optional and add a USE flag to build it; but |
| 48 |
say that the design of your tool doesn't allow for optional dependency |
| 49 |
detection so developers will need to split those out of the full |
| 50 |
dependency list. |
| 51 |
|
| 52 |
-- |
| 53 |
Thanks, |
| 54 |
Donnie |
| 55 |
|
| 56 |
Donnie Berkholz |
| 57 |
Admin, Summer of Code |
| 58 |
Gentoo Linux and X.Org |
| 59 |
Blog: http://dberkholz.com |
Archives