Hi,
We have been working on a new build model and UI for some time now.
Today we finally posted the first iteration of that work. Despite its
many short-comings, we felt that it was important to get it into the
hands of the CDT community now so that you can start playing with it
and provide your feedback on the direction we are going in.
Howto use the Build System
The key to success is to keep your expectations low. That said, here's
a cookbook for getting a simple executable up and running.
1. You must use a new managed project. Fortunately, there's a wizard
for creating them.
* Select File | New | Project
* Select 'C' or 'C++' in the left pane.
* You should see an entry 'Managed Make C (or C++) Project' in
the right pane. Highlight that and click 'Next'.
* Choose a name, then hit 'Next'.
* You *must* select the platform in the combo box (i.e. Cygwin
Executable even if it is selected).
* If you do, the check-list below will be populated with the
predefined configurations for that platform. If you must, you can
uncheck the one you don't want.
* At this point you can hit 'Finish' or proceed to meddle with
the binary parser and inter-project dependencies (although the builder
ignores dependencies right now ...)
2. Add a file or 2 (the class wizard that Hoda added is quite nice for
this).
3. Right click on the project in the navigator or C/C++ project view.
Select 'Properties' from the menu.
4. Select C/C++ Build from the list in the left pane. If it isn't
there, then you didn't use the right wizard to create your project.
5. It's pretty much self-explanatory from here (I hope). Select a tool
in the list, make some changes in a likely looking widget, and hit
'Apply'. See below for some limitations.
6. You can rebuild/build after this to see the makefile being
generated. Again, see below for limitations.
Limitations
Hmm. There are lots and lots of these, so I will try to summarize the
top-flight things that will trip you up for now.
1. There is only one toolchain defined in the patch that you can
access through the UI; namely for Cygwin. If you must try this
elsewhere, there is a Linux definition in the plugin.xml file for name
org.eclipse.cdt.ui. You can set the 'isTest' fields to false
and add some option categories and options. The Cygwin example is a
good starting point. Please note that the schema is still in flux, so
if you create and submit a new target, then we might have to update it
later.
2. So far, I have tested that it builds a simple executable
(HelloWorld is OK; your complex, multi-site project with 10M LOC is
not going to build just yet).
3. There is a target defined for static libraries, but I have not
tested it, and I wouldn't bet the farm that it builds anything.
4. There are no tools defined for yacc, Lex, Bison, etc .... Just
plain, vanilla C++ files.
5. While on the subject of C and C++ files, you will also note that
the g++ wrapper is called, even for C files. That will be addressed
when I return from holidays in a week.
6. The builder treats the last configuration you edited in the UI as
the current default. There is no visual cue to tell you which
configuration is the "default". However, it will effect the flags that
are used during build so this is something we have to address.
7. The builder is not very smart about what has changed and what needs
to be rebuilt. So, just do a full rebuild all the time if you want to
keep the makefile up-to-date.
8. The builder is not very smart about dependencies between source and
header files.
9. The builder is not very smart. Period.
10. The UI will not resize for really large pages. It is being
generated 'on the fly' based on the toolchain definition and that is
work yet to be done.
11. Switching between configurations is not as smooth as it could be.
Information is not lost, but you will have to reselect the tool. This
will be fixed, of course.
12. The manage configuration workflow has not been fully implemented.
I did not disable the 'Manage', but don't expect it to work and
please, no bugzilla reports on it, OK?
13. The command line summary tool is not implemented yet. It's on its
way.
A Final Word
Sam Robb provided an initial build model and UI, work we used as the
starting point for what we have posted so far. Doug Schaefer did all
of the architectural work on how the build model defines information
and more importantly, how it persists and recovers it. Both these
developers deserve the lion's share of the credit; they did the heavy
lifting. I just introduced the bugs. Enjoy.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada