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

["Robb, Sam" <sam.robb@xxxxxxxxxxx>]

> Sam> I've spent some time thinking about autotools integration
> Sam> as well, though purely from a consumer standpoint (import
> Sam> a project that is already autotools-based, as opposed to
> Sam> creating a new autotools project from scratch.)
> 
> I'm definitely interested in your thoughts -- if you've got a minute
> to write them up, please send them.  Hopefully once we start this
> process I'll be able to get the work done in public.  We'll see.

These are just some rough notes, more "wish list" than anything
else.  I've done a little experimentation, enough to at least
verify that the proposed directory structures and makefile control
mechanism are usable.

-Samrobb

1.  Importing a source archive

    Source archives come in various flavors: tar, tar.gz, tar.bz2,
    etc.  While the Java world uses zip as a more-or-less standard
    archive format, it would be very nice if CDT would provide
    parallel classes/structures for dealing with the formats commonly
    used for C/C++ packages.

    This would include utility classes for reading/writing these file
    formats (either directly in Java code, or through use of command
    line utilities) and one or more import/export wizards for these
    archive types.  The Eclipse zip file import/export wizards would
    be the cannonical example for the UI of the import/export wizards.

    When source is imported, there needs to be some way of determining
    if it is an autotools based project.  Simply checking for the
    presence of a configure script isn't neccesarily enough - I have
    come across projects that:

    - Had a top-level "configure" script that was not autoconf generated
    - Lacked a "configure" script, but had configure.in, etc.

    If a source archive is imported, but is determined to be non-auto*
    capable, then source import should proceed in the same manner as
    the zip import wizard - present a dialog to allow selection of
    files from the archive, etc.

    If a source archive is imported, and determined to be an auto*-
    based project, the user should be asked if they wish to set up
    the project to work with autotools, or if they just want to
    import the source as-is without any special considerations.

2.  GNU project nature

    If the user imports the source archive and indicates that it
    should supprot autotools, CDT should:

    - Add a new project nature (org.eclipse.cdt.gnude or the like)
      to identify the project as supporting autotools.  This step
      might be a bit tricky, as it might involve adding/removing
      other natures (C, C++) as well.
    - Unpack the archive into a subdirectory (src) instead of in
      the top-level directory for the project
    - Create a seperate subdirectory (build) if the project requires
      or can handle building in a seperate subdirectory.
    - Create a top-level Makefile with expected targets and any
      other useful targets.  This Makefile would be generated and
      maintained by the CDT autotools components.
    - Record gnude-specific settings into the CDT project file.

    Source is unpacked in a subdirectory specifically to seperate
    CDT maintained files (Makefiles) from the imported source.
    The generated Makefiles assume that the project can be built
    properly by a standard "configure; make" invocation on the
    command line.

    Using a seperate build directory supports those projects that
    require builddir != srcdir.  There is also the potential to
    use build subdirectories for different configurations.

    Settings present in the CDT project file might include:
    - name of source dir
    - name of build dir
    - whether or not the project uses a seperate build dir
    - options passed to configure

    In order to support command-line builds (ex, within an automated
    build system), the gnude builder should be very simple - call
    "make CFG=release", for example, to build a project with the
    options appropriate for a release build.  The generated Makefiles
    would handle things like determining if the project needs to
    be reconfigured for the selected configuration.  The gnude
    builder will probably need to be sensitive to changes in the
    auto* files in the source directory (ex, regenerating the configure
    script if any of it's inputs change, etc.)

3.  UI elements & related components

    Project properties for an auto* project include a project
    configuration pane.  This pane is superficially similar to
    the one used for managed make projects, in that it allows
    for multiple named build configs.

    An extremely simple auto* build config pane would include:
    - Toolchain selected for the build
    - Configure options (ex, --with-foo, --enable-bar) as raw text
    - Raw install options (ex, --prefix=/usr, etc.) as raw text

    In this case, the user (essentially) enters the arguments they
    want passed to configure.  These commands are injected into
    the generated Makefile(s) for each build config.

    A more complex auto* build config pane would use a parser to
    read a configure file (or configure.in, etc.) to determine
    what options the configure script understood.  This would
    allow the UI to enhance the presentation of options:

    - Seperate tabs could be presented, each dealing with a
      different logical set of options (intial configure options,
      build options, install options)
    - Options like "--with-foo" could be presented using a check
      box control with associated descriptive text.
    - Options like "--prefix" could be presented using a directory
      browser dialog to assist data entry, and verify the existance
      of the specified directory (or create a Makefile that attempts
      to create the directory as part of the build stage).
    - The user would be able to see what the default settings are
      (ex, --with-foo disabled, --prefix set to /usr/local, etc.)
    - The user would be able to see descriptive text for most
      options