1 |
On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: |
2 |
> internal functions should not be documented with the eclass doc comments |
3 |
> (_check_build_dir) |
4 |
|
5 |
Fixed. |
6 |
|
7 |
> reusing a PM variable (ECONF_SOURCE) seems a little iffy |
8 |
|
9 |
I know, initial idea was to use AUTOTOOLS_USE_DIR (analogy to CMAKE_USE_DIR), |
10 |
but then I discovered that I'd need to set ECONF_SOURCE anyway. So to avoid |
11 |
duplicating variables, I opted for ECONF_SOURCE reuse. If it's supposed to |
12 |
have internal meaning and is not part of public API, then I agree should not |
13 |
be used. I see it's explicitly mentioned in PMS though. |
14 |
Waiting for further comments on that matter. |
15 |
|
16 |
> the library handling is incorrect. i dont think you can pass around |
17 |
> --enable- shared all the time without having configure generate warnings |
18 |
> about unknown options. |
19 |
|
20 |
> default to --disable-static when static-libs |
21 |
> doesnt exist is wrong -- that's the opposite of what you should be doing. |
22 |
> ignoring the same issue as the share option i mentioned above. |
23 |
|
24 |
Right. It its safe to assume that when --disable-static/--enable-static is |
25 |
available, then --disable-shared/--enable-shared is available as well? |
26 |
|
27 |
> pushd/popd should have stdout sent to /dev/null, not stderr too |
28 |
|
29 |
Fixed. |
30 |
|
31 |
> the src_install func has the static-libs checks in the incorrect order |
32 |
|
33 |
Fixed. |
34 |
|
35 |
> the src_test func looks like its copying & pasting stuff from the PM. this |
36 |
> really should be kept in the PM without duplicating it everywhere. |
37 |
|
38 |
Unfortunately src_test needs to be called in build dir (which is unknown to |
39 |
PM). |
40 |
Calling default_src_test is the best I could come up with. |
41 |
|
42 |
But what's the most important - is there any interest in having such eclass? |
43 |
I'm only going to add it when it's flexible enough to effectively phase-out |
44 |
eutils/base/autotools/libtool individual uses for fully autotools-controlled |
45 |
buildsystems. Otherwise there's no point in yet another wrapper imho. |
46 |
|
47 |
I was also thinking of integrating parts of src_prepare from virtuoso.eclass |
48 |
into autotools-utils.eclass - it provides basic support for package splitting |
49 |
of well formed (TM) and clean autotools build systems. (example packages are |
50 |
virtuoso-odbc and virtuoso-server). |
51 |
|
52 |
Thanks |
53 |
|
54 |
-- |
55 |
regards |
56 |
MM |