Home > Archive > Software Engineering > November 2005 > Build environments for C++?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Build environments for C++?
|
|
|
| Is there anything better than using make for fairly large C++ projects
(or is make still the way to go)?
Could be an open-source, free or inexpensive commercial tool. It needs
to easily integrate with a SCM tool such as CVS, ClearCase, Perforce,
etc.
(probably needs to be command-line driven like make)
I want to hear from experienced users.
thanks in advance
Marco
| |
| William 2005-11-03, 6:59 pm |
| "Marco" <prenom_nomus@yahoo.com> wrote in message
news:1131031605.634980.128700@g14g2000cwa.googlegroups.com...
> Is there anything better than using make for fairly large C++ projects
> (or is make still the way to go)?
I've heard good things about jam (wish I could use it
myself): http://freetype.sourceforge.net/jam/
-Wm
| |
| Steve Christensen 2005-11-03, 6:59 pm |
| On 2005-11-03, William <Reply@NewsGroup.Please> wrote:
> "Marco" <prenom_nomus@yahoo.com> wrote in message
> news:1131031605.634980.128700@g14g2000cwa.googlegroups.com...
>
> I've heard good things about jam (wish I could use it
> myself): http://freetype.sourceforge.net/jam/
The Boost Build System, http://www.boost.org/tools/build, based on jam.
You should also check out SCons, http://www.scons.org
Being able to use a full programming language -- Python --for the build
scripts is fantastic. No more awful cobbling together m4 / perl / shell
for builds based around Make.
-Steve
--
The day he found out I could turn bacon into candy, he was mine forever.
-- Awillis, a.r.k.
| |
| Jorgen Grahn 2005-11-04, 6:59 pm |
| ["Followup-To:" header set to comp.software.config-mgmt.]
On 3 Nov 2005 07:26:45 -0800, Marco <prenom_nomus@yahoo.com> wrote:
> Is there anything better than using make for fairly large C++ projects
> (or is make still the way to go)?
Make is still a viable option. Neither size (in terms of source files) or
language (C++) should be a problem. Make's problems are elsewhere.
/Jorgen
--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
| |
| Eric Griswold 2005-11-04, 6:59 pm |
| "Marco" <prenom_nomus@yahoo.com> writes:
> Is there anything better than using make for fairly large C++ projects
> (or is make still the way to go)?
I've never actually used it (so caveat user), but scons has piqued
my interest, especially if your shop is Python-friendly.
www.scons.org
Eric
| |
| H. S. Lahman 2005-11-04, 6:59 pm |
| Responding to Marco...
> Is there anything better than using make for fairly large C++ projects
> (or is make still the way to go)?
I may be missing the point of your question, but my push back would be:
why not use an IDE that automates the build process so one doesn't have
to know whether make is used or not? (I can't recall looking at a make
file since the early '90s.)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
| Magnus Bäck 2005-11-07, 10:00 pm |
| On Fri, 04 Nov 2005 19:02:40 GMT,
"H. S. Lahman" <h.lahman@verizon.net> wrote:
> Responding to Marco...
>
>
> I may be missing the point of your question, but my push back would be:
> why not use an IDE that automates the build process so one doesn't have
> to know whether make is used or not? (I can't recall looking at a make
> file since the early '90s.)
Because that probably forces everyone to use that IDE, and secondly
if you want to set up scheduled builds etc on (possibly) headless
machines you better know something about what's under the hood of
the build process.
Many IDEs are fine, but I don't think it's a good idea to tie the
entire build process to them.
--
Magnus Bäck
baeck@swipnet.se
| |
| lohrer 2005-11-07, 10:00 pm |
| >
> You should also check out SCons, http://www.scons.org
>
> Being able to use a full programming language -- Python --for the build
> scripts is fantastic. No more awful cobbling together m4 / perl / shell
> for builds based around Make.
Yes, scons works just fine (and python is really  ). And because it
checks dependencies based on md5sums instead of time stamps, it also
works if some sources are located on remote shares, where you cannot
rely on time stamps being correct.
But because of this md5 check, it takes a long time (compared to make)
before the actual build starts.
- Marc
| |
| Ron Ruble 2005-11-07, 10:00 pm |
| H. S. Lahman wrote:
<snip>
> I may be missing the point of your question, but my push back would be:
> why not use an IDE that automates the build process so one doesn't have
> to know whether make is used or not? (I can't recall looking at a make
> file since the early '90s.)
A build environment, a la MAKE, can be used in a distributed or
automated fashion. If building the entire codebase takes 5 hours (or 45
hours), this can be a big advantage.
Many IDEs, -particularly- from MS, make frequent, unexpected changes to
the project configuration data. This can rapidly get out of sequence
between two developer machines. This sometimes results in intermittent
problems that only surface when the code is built on Joe's machine.
IDEs, and MAKE, tend to go off of the date time stamp on the file. As
noted in another reply, this can be problematic in some environments.
Other tools can use MD5 or other methods for determining if files should
be rebuilt.
IDEs are limited; they tend to be able to build one or a few types of
files. Sometimes it is necessary to do relatively complicated procedures
in building a full product. That's one reason some of the folks here
mentioned tools that support python scripting.
I've -very- frequently had to write various scripts for automating build
and deployment of products. Some of these were to update data in various
MS-Office binaries using COM. Maybe doable in an IDE, but not trivial.
There are probably many other reasons I don't know about, because my
work hasn't been affected; problems other people have encountered and
created a tool to solve.
| |
| H. S. Lahman 2005-11-07, 10:00 pm |
| Responding to Ruble (and Back)...
I guess that I am spoiled by translation environments where one doesn't
need to look at the 3GL code, much less make files. B-) So
unfortunately my detailed responses below come off as a commercial for
translation. However, the 3GL IDEs should be able to provide the same
automation and hooks for tailoring.
Also, I guess I didn't make it clear that I am not against make files.
I just want to see their processing as automated as possible. That is,
an application developer should never have to look at or understand make
file syntax except in extraordinary circumstances. (And then, mucking
with them should be a specialty that not everyone in the shop needs to
have.)
>
>
> A build environment, a la MAKE, can be used in a distributed or
> automated fashion. If building the entire codebase takes 5 hours (or 45
> hours), this can be a big advantage.
Once the distributed constraints are defined to the IDE, then this
should Just Work. Ideally one should only have to define the
constraints (e.g., where projects/files live) and the IDE should take
care of the rest.
[Translation almost always assumes that subsystems will be built
independently so each subsystem has its own make configuration and
subsystems can be virtually anywhere on the network. Going to parallel
processing for the overall build is then just a matter distributing the
subsystems and having a central message generator. (In R-T/E contexts
this is essential because the RTOS may not support sophisticated 3GLs or
debugging so one needs an inherently distributed build and execution
environment.)]
> Many IDEs, -particularly- from MS, make frequent, unexpected changes to
> the project configuration data. This can rapidly get out of sequence
> between two developer machines. This sometimes results in intermittent
> problems that only surface when the code is built on Joe's machine.
I am not arguing that one shouldn't have make files. I just think they
should be generated/processed automatically. The make file itself then
goes under version control. If everyone builds from the same "gold"
make (i.e., the IDE extracts it from version control for each build)
then there shouldn't be a synchronization problem across machines.
[Translation IDEs have a more complicated task because the 3GL source
code needs to be generated before it is compiled and linked. So one
tends to have multiple levels of make files. However, they are
generated automatically and the IDEs provide lots of hooks for tailoring
them. The synchronization, though, is built into the IDE.]
Changing the make file, of course, is a different problem that needs to
be controlled. For your example that seems like a vendor issue.
[Translation environments usually provide their own make facilities with
the IDE so it may or may not be a problem for a specific vendor. For
example, PathMATE employs a fairly elaborate "console" interface whose
mission in life is to define the configuration for the application,
subsystem by subsystem. It then generates scripts, templates, and make
files for later use by the IDE when automating code generation, builds,
and testing. Those scripts and templates are exposed so that in a worst
case scenario the customer can provide further customized tailoring.
But if a customer ever has to do that, then Pathfinder has screwed up by
omitting something from the console interface.]
> IDEs, and MAKE, tend to go off of the date time stamp on the file. As
> noted in another reply, this can be problematic in some environments.
> Other tools can use MD5 or other methods for determining if files should
> be rebuilt.
I agree time stamps are sometimes iffy, but that is still an IDE
implementation issue. If this can be an issue one needs to choose the
IDE more carefully.
[Translation IDEs typically have hooks so one can tailor the
configuration. So it is unlikely to be a major issue because one
defines the comparison mechanism once for the environment. Since
translation IDEs are usually closely integrated with version control,
they typically use an embedded version stamp anyway because they usually
extract all the files. Also, because they generate 3GL code on-the-fly,
all the 3GL sources will be compiled so only the order of compilation
usually matters for the 3GL make file.]
> IDEs are limited; they tend to be able to build one or a few types of
> files. Sometimes it is necessary to do relatively complicated procedures
> in building a full product. That's one reason some of the folks here
> mentioned tools that support python scripting.
[Not for translation. B-)) A transformation engine can generate
virtually any text-based language from the same UML model. For example,
the OTS PathMATE engine can currently generate C, C++, Java, CGI
scripts, or MS Word documentation from the same OOA model. That sort of
versatility comes with the territory.]
> I've -very- frequently had to write various scripts for automating build
> and deployment of products. Some of these were to update data in various
> MS-Office binaries using COM. Maybe doable in an IDE, but not trivial.
That's fine. I think every IDE should provide some sort of hooks for
tailoring the automation that it provides and exposing scripts is one
way to do that.
But as I read the original post the make file itself was to be manually
managed on an ongoing basis. I don't think the application developer
wants to be in that business one a regular basis. Any manual management
should be a reusable tailoring of existing automatic processes that
applies across all the shop's applications or is a one-time
implementation for a specific application. Once provided, the IDE
should handle the execution transparently for each build moving forward.
IOW, providing such scripts is a specialty that belongs to a different
union than the application developer's.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
| H. S. Lahman 2005-11-07, 10:00 pm |
| Responding to Bäck...
>
>
> Because that probably forces everyone to use that IDE, and secondly
> if you want to set up scheduled builds etc on (possibly) headless
> machines you better know something about what's under the hood of
> the build process.
See my response to Ruble concerning a number of details regarding your
second point. (And a bias implicit in my original post.)
As far as choosing an IDE is concerned, usually that is done for a
particular computing environment. When choosing such an IDE one must
consider a variety of issues, like what sort of software is being built,
how complex it is, how it is maintained, etc., etc.. But once the
<informed> decision is made, consistency in development (e.g.,
traceability of executables to version control) demands that everyone
should use it. I don't really see that as an option if the shop values
quality.
> Many IDEs are fine, but I don't think it's a good idea to tie the
> entire build process to them.
I agree, but I see this as a negotiation when selecting the IDE. The
benefits to productivity and quality of IDEs are too great to pass up.
OTOH, the IDE must fit into the shop's development environment and
culture with minimal hassle, so one needs to pick the right IDE.
But some compromises will probable have to be made. On the one hand,
one may have to select an IDE that doesn't have all the peripheral
features one might like because it is the only one that has all the
must-have features. Similarly, the optimal IDE may require some
adjustments to the build process.
For example, I am a translationist. Translation IDEs are enormously
powerful compared to traditional 3GL IDEs and they typically eliminate
the problems Ruble cited while offering huge gains in productivity.
OTOH, translation amounts to a major sea change compared to traditional
elaboration development. So any shop converting from elaboration to
translation is going to have to make some major adjustments in the way
they do things to reap those benefits.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
| miguelf 2005-11-07, 10:00 pm |
| It certainly seems like jam and SCons are nice viable options, as
people have suggested. In particular, I had thought of trying out SCons
because I like Python a lot, but I simply haven't had the time to learn
another tool.
However, the tool I'm using (and I highly recommend it) is CMake:
http://www.cmake.org/HTML/Index.html
It's open-source too, simple to write the "Makefile" (called
CMakeLists.txt) in. It will generate native makefiles and workspaces
that can be used in the compiler environment of your choice (MSVS 6.0,
..Net 2002, 2003, 2005 projects/solutions, Unix Makefiles, Borland,
etc).
It also integrates well with ctest/dart, a Unit Testing Framework and
nightly build system. I really find that this tool set
(cmake,ctest,dart) is a flexible, powerful and convenient build/test
environment.
For some example uses in quite large C++ projects, look at the doxygen
online docs or cvs repository of:
1. http://vxl.sourceforge.net/
2. http://public.kitware.com/VTK/
3. http://www.itk.org/
For a quick look at what ctest/dart is all about look at the CMake
dashboard (where the results of running them on the CMake sources
itself are collected online):
http://www.cmake.org/Testing/Dashbo.../Dashboard.html
VTK, VXL, ITK all have similar dashboards.
Hope this helps.
--Miguel
| |
| Michael Schneider 2005-11-07, 10:00 pm |
| Marco wrote:
> Is there anything better than using make for fairly large C++ projects
> (or is make still the way to go)?
>
>
> Could be an open-source, free or inexpensive commercial tool. It needs
> to easily integrate with a SCM tool such as CVS, ClearCase, Perforce,
> etc.
> (probably needs to be command-line driven like make)
>
>
>
> I want to hear from experienced users.
>
>
> thanks in advance
>
>
> Marco
>
Couple of questions:
- what do you mean by large (we deliver 2 15MLOC products)?
- On which platforms do you deliver your code?
- Are you planning on using a parallel build process?
- if yes how many machines on each platform?
- is testing included in your build process
- are you doing anything else in your build process then
compile/link C++ code? (build UI, lex/yacc/antlr....)
--
The greatest performance improvement occurs on the transition of from
the non-working state to the working state.
| |
| Jorgen Grahn 2005-11-07, 10:00 pm |
| ["Followup-To:" header set to comp.software.config-mgmt.]
On Sat, 05 Nov 2005 18:30:32 GMT, H. S. Lahman <h.lahman@verizon.net> wrote:
....
> Also, I guess I didn't make it clear that I am not against make files.
> I just want to see their processing as automated as possible. That is,
> an application developer should never have to look at or understand make
> file syntax except in extraordinary circumstances. (And then, mucking
> with them should be a specialty that not everyone in the shop needs to
> have.)
I don't quite follow your reasoning. To me, writing the Makefile is part of
the programming: that is, it's instructions for the computer, and
documentation for myself and others. Make is a programming language.
If I took away make, I would have to replace it with something else that did
approximately the same things based on the same basic ideas (following
dependency trees, while doing user-defined things). And everybody /still/
would have to understand how the whole thing fit together -- only they would
be looking at a new, unfamiliar syntax rather than Makefiles.
....
> I am not arguing that one shouldn't have make files. I just think they
> should be generated/processed automatically.
If they are generated and never modified or looked at, they are an
implementation detail. That would be the same thing as not having them,
IMHO.
BR,
/Jorgen
--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!
| |
| Robert Cowham 2005-11-09, 7:57 am |
| Steve Christensen <stnchris@xmission.com> wrote in
news:slrndml55k.e53.stnchris@xmission.xmission.com:
> On 2005-11-03, William <Reply@NewsGroup.Please> wrote:
>
> The Boost Build System, http://www.boost.org/tools/build, based on jam.
>
>
> You should also check out SCons, http://www.scons.org
>
> Being able to use a full programming language -- Python --for the build
> scripts is fantastic. No more awful cobbling together m4 / perl / shell
> for builds based around Make.
>
>
> -Steve
I've used both jam and scons very successfully. Currently prefer scons for
the Python abilities. Jam is good but a touch esoteric!
--
Robert Cowham
| |
| mdoar@pobox.com 2005-11-09, 6:59 pm |
| If you do use Jam, then I recommend using BoostJam, not the stock Jam
from Perforce. And a good editor to color the Jamfiles will help too.
~Matt
p.s. These build tools, and others, are compared in the my O'Reilly
book "Practical Development Environments"
(http://www.oreilly.com/catalog/practicalde)
| |
| Robert Cowham 2005-11-10, 6:59 pm |
| mdoar@pobox.com wrote in news:1131561737.430461.217390
@z14g2000cwz.googlegroups.com:
> If you do use Jam, then I recommend using BoostJam, not the stock Jam
> from Perforce. And a good editor to color the Jamfiles will help too.
I agree. BoostJam has introduced some useful extras.
--
Robert Cowham
|
|
|
|
|