| 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 |
Archives