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

[Tom Tromey <tromey@xxxxxxxxxx>]

>>>>> "Biswa" ==   <biswapesh.chattopadhyay@xxxxxx> writes:

I thought I'd post a note here about potential auto* integration
ideas.  Is this an ok forum?  I'm happy to move the conversation
somewhere else if that's preferred.

Biswa> Is there anything more concrete that 'plans in the near future'
Biswa> for autotools intgration, wizards and GNOME documentation
Biswa> integration ?

There's nothing concrete.  Red Hat is going to look at it, but we
don't have requirements or anything yet.  I've given it a fair amount
of thought though.

I'm definitely interested in hearing other people's ideas in this
area.  Send 'em on.  I'm happy to collect them and try to make some
sort of requirements/ideas page, if that's interesting to folks.

I'm just skipping your questions about gnome integration.  That looks
like a whole extra set of plugins to me.  (Though about the docs:
Chris Moller has working "hover help" code here, which we are going to
submit.  I don't know the timeline though.)

Biswa> b) What is the model I have to map to for the autotools build
Biswa> system ? Should I start with having a look at the manual
Biswa> Makefile ot Managed Make implementation ? Is there any sample
Biswa> dymmy implementation which I can use as the starting point ?

Biswa> e) Can you expand on your ideas on autotools integration ?

I think there are a few possible levels of implementation.  Some are
pretty easy (even mandatory :-) and some are more difficult.

One useful task would be looking at KDevelop and Anjuta and seeing
what they do.  We should aim for at least equivalent functionality.


The simplest thing is teaching the CDT that auto* exist at all.  The
idea here is to notice that a project has configure.in or
configure.ac, and automatically supply the necessary build steps.  At
least this should understand autoreconf (as many projects don't check
in the generated files), running configure, and running make.

The autoreconf step could check versions.  Some projects have a
`bootstrap' or `autogen' script that automates this.  I suspect we'll
want to ignore those as they vary a lot from project to project.

We could have parse the `configure --help' output and generate a
wizard that helps the user choose command-line options.

We could also automatically make the standard GNU build targets easily
available (clean, all, dist, etc -- there's a list in the GNU coding
standards, plus a couple useful automake extensions).

One important test scenario for this setup is "can I check out <random
GNU project> and build it with a couple clicks?".  Usually this should
be possible, there's a lot of uniformity among auto* projects.


Another relatively simple idea is an auto* wizard.  This would write a
stylized configure.in and Makefile.am according to your
specifications.  Perhaps it could be a conversion option from a
managed make project.  Or perhaps it could be an option of managed
make, the idea being that the Makefile.am would be a purely generated
file.


A more difficult task is "round trip" compatibility.  This is where
the CDT can parse the input files, knows enough to (e.g.) add new
files to the build automatically (or mostly so), and then later writes
out correct auto* input files.

Additional features in this mode would include integration with code
completion: you write unportable code, the plugin suggests a
workaround, or adds the necessary calls to configure.in, or adds the
required library checks or pkg-config calls.

I'd expect we could handle simple projects pretty well and fall back
on querying the user for the intractable cases.  There are a lot of
potential partial solutions in this space, it really depends on your
goals.


Versioning problems are tricky with auto*.  The world is slowly moving
forward, though, and I think it would be reasonable if the more
advanced features required new versions of the tools.  Trying to
support all shipping versions of auto* is probably a losing
proposition.

Tom