Matt,
Good luck in weaning your developers of Vis C++ building. I've heard from
some people on cciug that they have what you are planning, but it's a tough
sell when developers only compare compile speed and ease of debugging.
I still have something similar to your solution for NT and also have
separate makefiles for Unix (3 different Unix OSes, 1 makefile).
There is nothing wrong with cascading (I wouldn't call it recursive)
makefiles in my opinion. The benefit of being able to build single pieces is
nice. You can also have a separate target for each of the projects. It
depends a bit on how big your overall system is and how bit that makefile
ends up being and how often by how many people you expect updates.
As to what gets included in a config record: as long as the file included
resides in a vob, it will be in the config record. The config record is
written by monitoring the mvfs. Declared dependencies are added w/o
checking. So as long as all your builds are clearmake, you are actally
better off not writing too many detailed depencencies in your makefiles.
I actually ended up writing a makefile generator for our stuff here. Users
can pick some options that are available in the project and the generator
knows about all the hidden option, parameters, defs etc. Makefile syntax can
get quite tricky and usually has to be kept from users for the sanity of
everybody's mind. I ended up having a separate makefile for each directory
that gets called from the parent directory makefile. Some reasons for this
are historical though and you will end up possibly with unnecessary
rebuilds.
Btw. my genrator has an option to run makedepend (from the imake package) to
generate dependencies, as we do have one Ux platform that doesn't run CC.
I looked at imake, but didn't find any benefits for our needs. I think it is
ine of those tools that is great if you have to deliver for a ton of
different Oses, deliver source and a compile env - or know it already really
well.
You want to consider the following for your make system (in case you don't
already - some of these things are almost impossible to retrofit):
- being able to compile for several platforms in the same view (makes it
easy for developers to make sure their new change compiles/works on all
platforms before they check in)
possible solution: put DO's in a platform dependent sub dir, e.g. myunix,
NT, ....
- Make sure the system is maintainable (see al points below)
- have 1 central file per platform that drives compile, link parameters,
defines etc.
posible solution: have a params.myunix, params.NT, .... And include in the
makefile depending on which platform you are running on
- at the beginning of the project, invest some time in selecting the
compiler and other development tools. Check how C++ templates are handled,
if you are using them and what you need to do to make it all work with
clearmake. Maybe nothing, but you may end up with .ii ot .ti files that are
siblings, or worse yet get updated several times. This can be a lot of fun
regarding recompiles and wink-ins.
- Select one person from the project that is deeply involved in the
technical side of the project and define compile/link parameters to be used
for debug and release version. It may need some tweaking. The centrally
defined parameters are to be used for each compile
- Be warned that Ux and NT clearmake is "different". At least that is the
impression I've been getting from reading cciug for a few years. Also,
unless you deploy some ux toolkit, you are dealing with 2 different shells
that your makefiles are running in.
Also have a look at Christan Goetze
http://www.miaow.com/clearcase/ext/b.html
Martina
Don't Postpone Joy - Have Fun
Martina Riedel Siemens Enterprise Networks, Inc.
phone: 561-923-1774 Martina.Riedel@ICN.Siemens.com
-----Original Message-----
From: Matt Weiss [mailto:Matt.Weiss@apropos.com
Sent: Monday, July 02, 2001 5:13 PM
To: cciug@rational.com
Subject: [cciug] Makefile questions
Platform: WinNT only currently, eventually WinNT and Solaris 8, CC4.1
Currently we use omake -EN to build our product. The developer exports the
makefile from VC++. I maintain a system.mak file that recusively calls
omake on the exported makefile.
The system.mak file lives in the build VOB. We have another set of vobs
breaking the project to to logical pieces (i.e common components, client,
server, java, etc). Each VOB then contains a VC project in individual
folders.
\build
system.mak
\component
\dll1
dll1.dsp
dll1.mak
\dll2
etc.
Java builds are done with a call to javac.
Now that I also have the requirement of building UNIX, I finally can get rid
of the devstudio generated makefiles and go to something that would work for
both platforms using clearmake. I would also like to get rid of the
recursive calls to make, but will I also loose the ability to build the
individual projects?
By using include files to a master make, do the include files become part of
the config record or will there need a dependency on the project build
target?
I was wondering what other people did for their build systems. I need a way
to make sure the include pieces are easily updated by the developer as they
add new files and make sure they cannot accidentally break the makefiles.
Do people use particular makefile generators, dependency generators, or just
write their own tools?
I will try to search some more in the newsgroup archive but the link doesn't
seem to have been migrated to the new site yet.
Any suggestions or places to look for ideas are appreciated.
Matt.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 22:03:49 EDT