RE: [cdt-dev] Managed Make and how you use it

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

> >Some of these are addressed in CDT 2 and some in patches.  But 
> >my general concern that I'm trying to grasp is the state of 
> >the Managed Make facility in terms of flexibility.  Are most 
> >people finding that it fulfills their needs (it seems to be 
> >very .c/.cpp to executable centric)? 

We've run into a similar problem, where a customer wanted to
designate an arbitrary file extension as being a C/C++ source
file, and have it participate in the IDE as a first-class
citizen (ex, show up in the outline view, available via the
indexer, etc.)

You can use the Eclipse facilities to designate the file as
having the C/C++ editor as it's default, but that doesn't do
anything to solve the problem of having it particpate elsewhere.

I'd suggest an extension mapping facility, so that users can
define (on a workspace level) how to map a file name onto a
file type, ex:

  *.c   --> { lang="c" type="source" origin="org.eclipse.cdt" }
  *.cpp --> { lang="c" type="source" origin="org.eclipse.cdt" }
  *.h   --> { lang="c,c++" type="header" origin="org.eclipse.cdt" }
  *.inl --> { lang="c" type="header" origin="user" }
  *.idl --> { lang="idl" type="source" origin="org.neato-cdt-plugins.midl" }

Putting together a preference page, edit dialogs, etc. would be
pretty straightforward work.  The hard part would be finding all
the various places that have hardcoded assumptions about file types
and changing them over to use a type resolution API.

If anyone else has a better solution, I'd like to hear it... if
not, then I'd be happy to do a bit more research and put together
a more formal suggestion.

> >Or do are a lot of 
> >people rolling their own managed make (seemed that way at 
> >EclipseCon)?  Any common technique you're using for 
> >extending/reusing Managed Make (e.g. inheriting from most 
> >classes, or just rewrite your own classes)?
>
> We at QNX are moving away from our own "flavour" of managed make and
> are moving towards ensuring that the CDT managed make either meets or
> provides the extensions required to meet our needs (via patches and
> discussions).  This work has not yet started in earnest.

Fow what it's worth, this is the same attitude we have here
at TimeSys; we want to help improve the CDT managed build
system.  We'd rather get the features we want/need into the
CDT managed build than have to maintain our own managed build
system.

-Samrobb