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 |