| 1 |
Hi all, |
| 2 |
|
| 3 |
A friend of mine and myself are willing to develop some tools to help ebuild |
| 4 |
development. |
| 5 |
|
| 6 |
We have some constraints, but we are thinking on something like: |
| 7 |
1) A tool to ease writing ebuilds. It would take some parameters, i.e.: |
| 8 |
1.1) Where are the sources? |
| 9 |
1.2) Decompression algorithm? |
| 10 |
1.3) Compile the sources? |
| 11 |
1.4) Install man page(s)? |
| 12 |
1.5) Install documentation? |
| 13 |
1.6) Bind actions to USE flags? |
| 14 |
It would probably be interesting to define a set of pre-defined categories: |
| 15 |
standard GNU Autotools projects, perl/CPAN modules, python, ... |
| 16 |
|
| 17 |
2) A tool to deal with the unstandarized way to compile and install Java |
| 18 |
projects. The idea is to write a tool to try to find out: |
| 19 |
2.1) Where are located the "main" .java sources. |
| 20 |
2.2) Where are located the unit tests. |
| 21 |
2.3) Where are the jar files generated (in case of Ant-based builds) when |
| 22 |
the project is built. |
| 23 |
2.4) Where to get the dependencies. |
| 24 |
And once this information is available, fill the blanks of a pre-defined |
| 25 |
Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it would |
| 26 |
allow compilation flags even if the original build mechanism didn't. |
| 27 |
We probably will ask for this specific issue to gentoo-java mailing list. We |
| 28 |
don't think a fully-automated tool is feasible to cope with all kind of |
| 29 |
projects, but we hope it could be of use for Java developers who don't use |
| 30 |
Gentoo but find interesting to get an ebuild with little effort. |
| 31 |
|
| 32 |
However, we are just in the definition stage. We haven't decided anything yet, |
| 33 |
and would like to know your suggestions, even if they aren't encouraging :). |
| 34 |
|
| 35 |
Thank you very much. |
| 36 |
Jose. |
Archives