Re: [cdt-dev] CDT Conference call - Build Model Docs

["Alain Magloire" <alain@xxxxxxx>]

> > It was not clear to me how those other builders can plugin=20
> > within the CDT.
> > Unless the answer is: if you use the IDE you got to use the=20
> > Build of the CDT.
> 
> It seems like there are two ways to do this:
> 
> - Provide an abstract builder that is used to implement the default
>   CDT builder.  ISVs could use the capabilities of the abstract
>   builder to implement a custom builder as desired.
> 
> - Provide a default builder that is driven in part or in whole by the
>   toolchain.  The default builder would order resource builds to
>   fulfill dependencies reported by the toolchain.
> 
> A combination of the two would probably work best - develop a
> flexible builder that relies on the toolchain to encapsulate
> knowledge about how to build things properly, but make it a
> straightfoward task to derive a completely different builder.
> 

Yes, see other post.

> 
> I don't see any reason at all to drop the current builder - if
> nothing else, there are probably hundreds of thousands of projects
> (open source and corporate) that have hand-made Makefiles and
> build scripts.  I've actually got a handful of these that I have
> used the current version of CDT with.
> 
> I don't know what the best method of handling this is, though.
> In TS2, we use a project property to indicate if the Makefile
> is to be maintained automatically or simply used as-is.  Perhaps
> a similar flag on projects is called for (use internal builder
> vs. use external build command).
> =20

Agreed, something was missing though, a UI component to let
the build model be aware of some info, include_paths, src_paths etc ..
It could have been fetch by parsing or let the user enter it.
Allowing the other parts debugger/parser/outliner/ etc ..
to make smarter decisions.

See post from Sean on this too.

> > =3D=3D scenario 3: Information for other modules.
> > For example, the debugger needs to know the src paths for the=20
> > sourceLocator to find
> > files when stepping.  The parser may need some macros,=20
> > definition to do parsing
> > correctly.  The indexer, search, refactor may also need the=20
> > include paths, in C++
> > the entire definition of the class can be inline in a header,=20
> > the class definition
> > is needed to do correct code complete/assist.  Some work was=20
> > started in the=20
> > ICBuilder but we did not have a chance to refine.
> 
> All these pieces of information (source file locations, macros,
> include paths, etc.) should be exposed by the build model in a
> generic way.  One way to do this is to add convenience methods
> to the ICBuildConfig interface to retrieve standard information
> (getSourcePaths(), getIncludePaths(), get getCppMacros(), etc.)
> 


> > =3D=3D scenario 4: Extension points.
> > Can it(should it) be possible to overload the entire Build Model?
> 
> I don't know.  My inclination is to say "no", though others may
> disagree.
> 

My is to say "yes" 8-)

> > Where the other extension points?  for example for the error parsers ?
> 
> Not present yet.  Still a work in progress.
> =20
> > =3D=3D scenario 5: Integration with the current CDT
> > In the CDT core there is a framework for extension points it=20
> > is save in the
> > project, in a ".cdtproject" file.  The ".cdtproject" file is=20
> > somehow equivalent
> > to the ".project" but for the CDT so it is possible to=20
> > export/share information.
> > For example when checking out a C/C++ Project, the binary=20
> > parser type, build model type
> > etc .. can be shared.  Here is an example of what is generated now:
> >=20
> > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> > <cdtproject id=3D"org.eclipse.cdt.core.make">
> >     <extension id=3D"org.eclipse.cdt.core.makeBuilder"=20
> > point=3D"org.eclipse.cdt.core.CBuildModel">
> >         <attribute key=3D"command" value=3D"make"/>
> >     </extension>
> > </cdtproject>
> >=20
> > Sharing properties/settings(via cvs or other means), seems to=20
> > be important for some of our
> > customers .. they even ask to share breakpoints ... sigh ..
> 
> The current implementation is set up to save build config settings
> to one or more files (one per build configuration).  The files are
> plain text, modeled after launcher config files, and exist explicitly
> because of the need to share build configs.
> 
> Having one file (.cdtconfig) or merging the configuration information
> into the .cdtproject file is possible.  Is there an way to inject (and
> later extract) arbitrary information into the .cdtproject file?
> 

Yes.

I would say to try to limit on the proliferation of config files.
The ".cdtproject" seems like a nice place to put this in, there is current
code in the CDT to do this,  I'll try to get all this document and submit
back a proposition here.

> Haven't implemented this yet, but the concept of "currently active
> build configuration" for a project probably should be a local,
> persistent project property.
>