[gentoo-dev] Suggestion

[gentoo-dev] Suggestion

[Jose San Leandro]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

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, ...

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.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Suggestion

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

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/


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Suggestion

[Christopher Covington]

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

Re: [gentoo-dev] Suggestion

[Joshua Nichols]

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

[gentoo-dev] Re: Suggestion

[Steve Long]

> 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

Re: [gentoo-dev] Suggestion

[Jose San Leandro]

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

Re: [gentoo-dev] Suggestion

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Suggestion

[Luis Francisco Araujo]

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

Re: [gentoo-dev] Suggestion

[Alistair Bush]

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

[gentoo-dev] suggestion...

[Andy Molloy]

Just a friendly suggestion...  In the install instructions, it might be 
nice to mention that you have to run rc-update on your choice of cron 
and logger, and even mention that you will have to do this for any 
service you install. For those of us more accustomed to the "we do 
everything for you" installers, it could save us a few minutes time.

Otherwise, the instructions are very clear and easy to understand. I got 
Gentoo Linux up and running in no time, and am really enjoying it quite 
a bit!

Thanks-
Andy Molloy