RE: [cdt-core-dev] Re: [cdt-dev] Building a GNOME IDE for Eclipse

[<biswapesh.chattopadhyay@xxxxxx>]

<snip>

> Hi,
> 
> I don't think it is possible to integrate autotools into ide 
> when every 
>   distro has different versions of Autoconf, Automake etc. Even small 
> bugs in generated scripts are very difficult to fix, since very small 
> number of developers completely understands the way autotools (in 
> different versions) works. Maybe it would be enough to create "Export 

I disagree. I do not think it is necessary to have a perfect understanding of the differences in generated scripts by different autotools versions to have a working autotools based build mechanism.

Here's a gross overview of how I think the autotools based build system should work:

1) Import an existing/generated autotools project: This feature will take the top level directory of an existing project (or a tarball/CVS details/SRPM/etc.) and derive the current structure. There are two distinct parts of this activity:
	a) Recursively parse Makefile.am files starting from the topmost Makefile.am and using the SUBDIRS variable to recursively traverse to child directories. At each directory level, look at _PROGRAMS, _SOURCES, etc. to build a structure of all targets, dependencies, flags, etc. For this we need a Makefile.am parser which is not very difficult to write, esp. if we use Perl code from automake to parse the files. We will, of course, need configuration and user input for things like conditional definition of SUBDIRS, PROGRAMS, etc. The Makefile.am files contain sufficient information to get virtually all details of building the project.
	b) Parse configure.in. We will have to store the result in an internal representation, consisting mainly of two types of lines: simple shells and autoconf macro invocations. We might need to run aclocal before if aclocal.m4 is missing and pars e that to get a list of available macros and their parameters. Again, writing such a parser should not be difficult, esp. if we use perl code from autoconf (I believe KDevelop already does something like this, and there is also some code in the anjuta2 project to achieve this)

New autotools projecs should be treated as a combination of generation of a code tree and then using the import utility to parse the required files.

2) Allow editing of the build DOM. This is the difficult part, but not severely so. This requires the following considerations:
	a) Allow users to manipulate targets, their dependencies and various other parameters, e.g. flags. Writing a frontend for this should not be difficult - we could probably reuse code from other build frontends.
	b) Allow users to manuipulate build options and dependencies (i.e, configure.in). This is probably a bit more difficult. What we need is a graphical configure.in editor. However, we can start with a simpler editor. Since we already habve a list o available macros and their parametetrs from the parsing step in (1), we can provide intellisense help to the user to modify configure.in. We can also have a list of readymade snippets for the more common tasks.
	c) We need to be able to write the modified DOM back to a set of Makefile.am and configure.in. We need to be careful here to allow for manual editing and ensure that we preserve verbatim parts of files that we have not touched or understood. This is, again, quite doable IMO.

3) Invocation of build commands. This is really the simplest parts - we need to have menu items for standard commands such as './configure', 'make', 'make install', etc. If the configure parsers works correctly, it should be possible to show the configure options available to the user and ask for inputs (e.g. ./configure --prefix=..)

I hope this makes sense. We need to decide how much of this shoiuld be writen in Java and how much in perl. Are there are PCRE (www.pcre.org) bindings for Java BTW ? Then we can write the whole thing in Java I would say.

Of course, let me reiterate: I am completely new to Eclipse and Java, so things might be quite a bit of from how hese things are handled in the Eclipse ramework - in which case, please feel free to corect me/guide me in the right direction. I intend to do some serious reading of Eclipse documentation and take myself through some Java tutorials soon.

> workspace to .tar.gz" option with some parameters for "make install" 
> step. I mean parameters like what files goes into which folder.
> 
> mirza
> 
> 
> 
> 
> _______________________________________________
> cdt-core-dev mailing list
> cdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
>