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

["Alain Magloire" <alain@xxxxxxx>]

> 

oops! missed your email!
(off topic: I need to work on GNU mailutils to add some filtering ....)

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

We should probably do this on cdt-core-dev@xxxxxxxxxxx
instead of the general cdt-dev.

> 
 ...

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

Yes!!!
Exactly what I had in mind, for automake.


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

Agreed.

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

Agreed.