Mailing List Archive

On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro
<jose.sanleandro@ventura24.es> wrote:
| A friend of mine and myself are willing to develop some tools to help
| ebuild development.

All the common cases should be handled by default functions, package
manager functions and eclasses. Thus, writing ebuilds should consist
merely of handling unique or uncommon special cases, and the best tool
for doing that is an ebuild-aware text editor.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/

On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
> Hi all,
>
> A friend of mine and myself are willing to develop some tools to help
> ebuild development.
>
> We have some constraints, but we are thinking on something like:
> 1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
> 1.1) Where are the sources?
> 1.2) Decompression algorithm?
> 1.3) Compile the sources?
> 1.4) Install man page(s)?
> 1.5) Install documentation?
> 1.6) Bind actions to USE flags?
> It would probably be interesting to define a set of pre-defined categories:
> standard GNU Autotools projects, perl/CPAN modules, python, ...

I see no reason why a good template and/or eclass can't handle this
>
> 2) A tool to deal with the unstandarized way to compile and install Java
> projects. The idea is to write a tool to try to find out:
> 2.1) Where are located the "main" .java sources.
> 2.2) Where are located the unit tests.
> 2.3) Where are the jar files generated (in case of Ant-based builds) when
> the project is built.
> 2.4) Where to get the dependencies.
> And once this information is available, fill the blanks of a pre-defined
> Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
> would allow compilation flags even if the original build mechanism didn't.
> We probably will ask for this specific issue to gentoo-java mailing list.
> We don't think a fully-automated tool is feasible to cope with all kind of
> projects, but we hope it could be of use for Java developers who don't use
> Gentoo but find interesting to get an ebuild with little effort.

I apologies as this will be critical.

Firstly I would be very interested in how you would handle to dependencies of
a package within this build system. Maven is natorious for wanting to
download its dependencies (including plugins all its plugins) from a remote
repository. Something that the java team (and me personally) have been
struggling with for sometime.

Secondly the java-*-2 eclasses are now very advanced wrt everything ant.
They abstract a large portion of the functionality away from the ebuild
(without lossing the flexability)

So here an anottated vim template that I currently use and that will hopefully
( bug #164953 ) make it into the tree.


# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

JAVA_PKG_IUSE="doc source" #this appends the appropriate deps to
#DEPEND(RDEPEND) for source

inherit java-pkg-2 java-ant-2

DESCRIPTION=""
HOMEPAGE=""
SRC_URI="${P}.zip"

LICENSE=""
SLOT="0"
KEYWORDS="~amd64"

IUSE=""

COMMON_DEP=""

RDEPEND=">=virtual/jre-1.4 #this is used by eclasses to determine the target
class version
${COMMON_DEP}"
DEPEND=">=virtual/jdk-1.4 #and this determines the source target
app-arch/unzip
${COMMON_DEP}"

EANT_BUILD_TARGET=""
EANT_DOC_TARGET=""

src_install() {
java-pkg_dojar "${PN}.jar"
use doc && java-pkg_dojavadoc build/javadoc
use source && java-pkg_dosrc src
}

I find this ebuild template usually provides everything a java ebuild
requires.

I would suggest you read the dev notes on the gentoo-java project page as well
as reading the wiki.

>
> However, we are just in the definition stage. We haven't decided anything
> yet, and would like to know your suggestions, even if they aren't
> encouraging :).
>
> Thank you very much.
> Jose.

Please don't let me discourage you. I would be very interested in your
solutions for using maven and I believe the when 2.0.5 is released some form
of pom re-writing could be possible (similar to what happens with build.xml
files at the moment), but I dont believe there is a need to mavenify ant
builds. I believe it would be over complicated and have huge problems
handling where the src and libraries within a package reside. When it comes
to ant (at least) I believe the present solution is far more adaptable and
productive.


Alistair
--
gentoo-dev@gentoo.org mailing list

Apropos ebuild-aware text editor, has anyone written an eclipse plugin
yet? I find that setting up ebuild as an external tool is basically
all I need but syntax highlighting and eclass reference would make
things prettier.

On 2/8/07, Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro
> <jose.sanleandro@ventura24.es> wrote:
> | A friend of mine and myself are willing to develop some tools to help
> | ebuild development.
>
> All the common cases should be handled by default functions, package
> manager functions and eclasses. Thus, writing ebuilds should consist
> merely of handling unique or uncommon special cases, and the best tool
> for doing that is an ebuild-aware text editor.
>
> --
> Ciaran McCreesh
> Mail : ciaranm at ciaranm.org
> Web : http://ciaranm.org/
> Paludis, the secure package manager : http://paludis.pioto.org/
>
>
>
--
gentoo-dev@gentoo.org mailing list

That is enough once you know how to write ebuilds.

We were thinking of a GUI to soften the learning curve to non-experts.
Probably not useful for a Gentoo developer, but could provide an easy way to
write ebuilds to project maintainers themselves, not to Gentoo resources.

On Thursday 08 February 2007 10:43, Ciaran McCreesh wrote:
> On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro
>
> <jose.sanleandro@ventura24.es> wrote:
> | A friend of mine and myself are willing to develop some tools to help
> | ebuild development.
>
> All the common cases should be handled by default functions, package
> manager functions and eclasses. Thus, writing ebuilds should consist
> merely of handling unique or uncommon special cases, and the best tool
> for doing that is an ebuild-aware text editor.
--
gentoo-dev@gentoo.org mailing list

On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote:
> That is enough once you know how to write ebuilds.
>
> We were thinking of a GUI to soften the learning curve to non-experts.
> Probably not useful for a Gentoo developer, but could provide an easy way to
> write ebuilds to project maintainers themselves, not to Gentoo resources.

I think what everyone means here is that if the default functions don't
cover it, and an eclass doesn't cover it, then all of the code will have
to be written by hand, anyway. No amount of pretty clicky interfaces
will help this.

The only thing I would really see as being useful would be a simple help
system that is aware of all of the functions in ebuilds. This could be
possible if there were some standardized way to document functions and
their uses, so it could be parsed at run-time from the tree itself, but
currently, I don't see it getting much traction. Don't get me wrong, I
see lots of places where work could be done to make things easier, such
as some way to easily determine dependencies. I just don't think it is
possible to write up an IDE until more work is done defining the current
eclasses and functions into something more static.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

Christopher Covington wrote:
> Apropos ebuild-aware text editor, has anyone written an eclipse plugin
> yet? I find that setting up ebuild as an external tool is basically
> all I need but syntax highlighting and eclass reference would make
> things prettier.
>
I have no idea of the status, but I recently heard about:
http://sourceforge.net/projects/geclipse/

--
Joshua Nichols
Gentoo/Java Project Lead
Gentoo/Xfce Project Lead
--
gentoo-dev@gentoo.org mailing list

Chris Gianelloni wrote:
> On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote:
>> That is enough once you know how to write ebuilds.
>>
>> We were thinking of a GUI to soften the learning curve to non-experts.
>> Probably not useful for a Gentoo developer, but could provide an easy way to
>> write ebuilds to project maintainers themselves, not to Gentoo resources.
>
> I think what everyone means here is that if the default functions don't
> cover it, and an eclass doesn't cover it, then all of the code will have
> to be written by hand, anyway. No amount of pretty clicky interfaces
> will help this.
>
> The only thing I would really see as being useful would be a simple help
> system that is aware of all of the functions in ebuilds. This could be
> possible if there were some standardized way to document functions and
> their uses, so it could be parsed at run-time from the tree itself, but
> currently, I don't see it getting much traction. Don't get me wrong, I
> see lots of places where work could be done to make things easier, such
> as some way to easily determine dependencies. I just don't think it is
> possible to write up an IDE until more work is done defining the current
> eclasses and functions into something more static.
>

It'd be very difficult to replace just 'opening a text editor' by an
IDE. Though you might probably come up with very cool ideas ; like for
example, an eclass browser that could search function based on name or
descriptions of what the developer is looking for; probably with some
hierarchy view for surfing them.

At the end, i guess a text editor would be the best option; but that
doesn't mean you can't try new methods/ideas.

Regards,

--

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list

> On 2/8/07, Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
>> On Thu, 8 Feb 2007 10:38:08 +0100 Jose San Leandro
>> <jose.sanleandro@ventura24.es> wrote:
>> | A friend of mine and myself are willing to develop some tools to help
>> | ebuild development.
>>
>> All the common cases should be handled by default functions, package
>> manager functions and eclasses. Thus, writing ebuilds should consist
>> merely of handling unique or uncommon special cases, and the best tool
>> for doing that is an ebuild-aware text editor.
>>
Christopher Covington wrote:
> Apropos ebuild-aware text editor, has anyone written an eclipse plugin
> yet? I find that setting up ebuild as an external tool is basically
> all I need but syntax highlighting and eclass reference would make
> things prettier.
>
Personally I find kwrite or kate to be excellent. I guess kate if you want
to set up tools etc. Have looked at the bash syntax highlighting xml for
katepart in (~|/usr/share)/apps/katepart/ and it's an excellent basis. Am
hacking it now to add ebuild functions, but if anyone knows a bit more
about this (specifically writing rules) and is willing to help, please mail
me.


--
gentoo-dev@gentoo.org mailing list