Hi,
I've received several messages from you, but haven't had time to give
the more technical messages proper understanding. I'll try to answer
these questions though.
>>> Masatake YAMATO <jet@...> seems to think that:
>I'd like to introduce myself to be involved in cedet.
>
>My interests on cedet are
>1) Better automake/Makefile.am support (as I posted).
>2) Sourceforge/Savannah/Gforge/Freshmeat support.
>
>1) Better automake/Makefile.am support (as I posted).
>What I want is just importing Makefile.am. I'll edit Makefile.am
>by my hand. No extra interface is needed. However importing must
>be perfect. I hope pickmake helps us to import. If importing works
>well, what I want next are:
There is an existing parser for Makefile.am in EDE which is pretty
simple. EDE can then add/remove files to/from the makefile
directly. The alternate EDE interface to makefile.am has a project
file, and genarates the Makefile.am file automatically, which is less
convenient if you need to use features not supported in EDE
>1.1 M-x find-file-in-current-project
EDE already interfaces with semantic to provide a project root for
searching. This sounds like a useful function too.
>1.2 Buffer grouping for M-x switch-to-buffer-in-current-project
>1.3 Project local variable
These already exist, though I don't recall if they are in the
Makefile.am version.
>1.4 Project local data storage
I'm not sure how this is different from project local variables.
>I don't know 1.1, 1.2 and 1.3 are already implemented or not.
>About 1.4, I think Project.ede is used. However, if Makefile.am
>based project, where extra project loca data should be put?
That's an interesting question. I think you can drop any kind of
data you want in Makefile.am as long is the name is not special.
>2) Sourceforge/Savannah/Gforge/Freshmeat support
>How do you think extending ede-system.el?
>Mailing list, ftp, web site, future request ... provided by
>sourceforge should be controlled under EDE.
I submitted an enhancement request to sourceforge so I could automate
the process. The are (or have) implemented an XML interface to
project management that can be used.
>M-x send-report-to-currenrt-project-bug-tracking
>M-x read-post-of-currenrt-project-bug-tracking
>
>M-x send-mail-to-currenrt-project-development-mailing-list
>M-x read-mail-to-currenrt-project-development-mailing-list
That's a good idea.
>Class hierarchy
>
>development-enviroment
> local
> remote
> sourceforge
> savannah
> gforge
>
I see, a set of objects for accessing remote environments that is a
part of the EDE project hierarchy. That could be a whole new project
separate from EDE. EDE worry up to the point of creating a .tar
file, and the second package could manage the project after that.
>Project announcement efforts are important for free software
>developers. Freshmeat is well know announcement site.
>How do you think provide M-x interface to post an announcement
>article to the site like freshmeat?
>
>M-x new-release-announce-for-current-proejct
>
>Class hierarchy
>
>development-enviroment
> web
> freshmeat
> ???
> ???
>
CEDET has a www directory, and EDE can find web pages associated with
a project (for Project.ede based projects).
These sound like interesting ideas. For better Makefile.am support,
it would make sense to use semantic to create a Makefile.am parser,
which is probably the same as exists for Makefiles. That could
simplify the parsing step.
Of all the things EDE does, most surely the most complex is Makefile
generation. There are so many little bits to keep track of and order
just so for a good Makefile that the methods that create them get
quite messy and hard to document.
Sounds like fun!
Eric
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|