RE: [cdt-dev] Managed Build Questions

[djlynott@xxxxxxxxxxxxxxxxxxx]

cdt-dev-bounces@xxxxxxxxxxx wrote on 11/06/2007 10:41:56
PM:

> 
> --- "Brunauer, Walter" <Walter.Brunauer@xxxxxxxxxxxxx>
> wrote:
> 
> > Hi Robert,
> > 
> > I was expecting this feature as well, but unless I
> > am missing something,
> > CDT is still not able to handle multiple build
> > artifacts within the same
> > project.
> > 
> > I guess, all you could do is to split up your
> > project into n...
> > 
> > Cheers,
> > 
> > Walter
> > 
> > PS: And while we are at it: anybody knows, how one
> > could switch from
> > internal to external builder? Seems, the
> > corresponding property page is
> > always completely disabled...
> > 
> 
> Hello Walter,
> 
> Yup it's disabled initially in C/C++ Build->Builder
> Settings, but once you change 'Current Builder' in
> C/C++ Build->Tool chain editor to 'Gnu Make Builder'
> it becomes changeable in C/C++ Build->Builder Settings
> (regardless of whether you return it to Internal
> Builder again, anywhere).
> 
> I wonder if this is intended behavior, as it seems
> inconsistent to me.
> 
> Best regards,
> Ron

This seemed non-intuitive to me as well... as does
the
manage configurations dialog where we are stuck with
the
configurations of our "current" toolchain.
I was wondering
how CDT planned on addressing that use case in the
future?

I've had peers also frustrated with the lack of support
for multiple build artifacts per project. I did most
of
my C++ coding within Dev Studio 5/6 and felt their
sub-
project abstraction was fairly intuitive. I suppose
in some
ways this would be like project references within
CDT.
One thing I would like to see is settings applied
consistently
across a number of projects (i.e. library projects
that 
feed into the final executable project). Having users
maintain
these separate for each individual project seems to
put a 
lot of work on the user. It also seems to be sort
of a 
maintenance nightmare. I know how I want my final
executable
built (perhaps with exceptions enabled) but the library
projects may not be setup correctly and then I have
to edit
each library to add configurations that match the
final
artifact project. Perhaps what is needed is some sort
of
configuration inheritance? Perhaps the project that
builds
the final artifact controls the compile flags of all
subprojects?

I've managed to build up some test cases where I have
an
executable and some dependent library projects. The
only
way I can get the dependencies to work out correctly
is to
name all the configurations for the projects the same.
While this works, like I said earlier... it is a time-
consuming process. If one of the dependencies does
not have
a configuration with that name, the build fails.

I'm really frustrated as I would like to use CDT with
as
few changes as possible internally at my company.
I want all
C/C++ toolchains to look and behave similar. Tools
from vendors
like QNX and Wind River seem to correct these user-interface
deficiencies but do not interoperate. In fact, our
company
had to go off and do something similar to both these
vendors...
roll our own UI. We use the internal CDT model, parsers,
etc.
Our single largest complaint from our users is that
there is
this "unused" UI stuff hanging around that
confuses them.

Each release we re-evaluate the CDT and try to see
if we can
just write simple plugins to address our cross compilers
and
still have the multiple configuration support our
users require
and eliminate our UI code. I was really hopeful we
could do
this with CDT 4.0. We still have the following areas
of concern:

  - Support for multiple configurations and toolchains
is a major
    step toward where we need to be. A bit
more work on managing 
    configurations could go a long way.
It seems like it should
    work like the initial project setup
wizard (choose a
    toolchain, then a default configuration).
An option for
    basing it on an existing configuration
should also be
    available (any existing configuration...
not just one
    for the current toolchain, perhaps even
import from another
    location?).
  - C and C++ share many compiler settings. These
settings
    "should" be common and not
specified for each tool. I am
    not alone on this issue... I have yet
to meet a seasoned C++
    developer that believes specifying includes,
debug, 
    optimization flags and other common
settings separate 
    for each toolchain is the majority use-case.
  - When a project has multiple configurations
with these
    configurations specifying different
toolchains, the binary
    parser(s) for the first configuration
created are the only
    ones that appear to parse the final
artifacts. The reason
    this is unacceptable is that if CDT
cannot determine what
    the artifact that was just built is...
it cannot find it
    for debugging (or execution). This seems
to just be a bug
    with the current CDT.

These are simply my observations as a developer and
someone trying
to extend the product. We're happy that multiple configurations
has been added this go around. Things are getting
closer to our
desired state.

Regards,
-- Dave