Re: Gaining control of build dependency...
From: Brendan Tregear (brendantregear_at_hotmail.com)
Date: 08/12/03
- Next message: Tom Linden: "RE: Gaining control of build dependency..."
- Previous message: Bill Todd: "Re: IBM Beats HP for Computing Deal with Lego"
- In reply to: Tom Linden: "RE: Gaining control of build dependency..."
- Next in thread: Tom Linden: "RE: Gaining control of build dependency..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 11 Aug 2003 18:25:52 -0700
Hi All,
I thought I'd make a final posting on how I solved this, in case any
poor souls in the future strike the same problem :)
Firstly, Tom, I had a look at using suffix rules, but I don't think
this can solve the problem - we need to update the include file before
dependencies are checked, not before compilation.
Secondly, Bob's suggestion got me going down the right path:
descrip.mms:
local_include_file DEPENDS_ON global_include_file
RUN UTILITY COM FILE
MMS/DESCRIPTION=descrip2.mms
descrip2.mms:
my_source_file DEPENDS_ON local_include_file
This works great. Now the only problem is that the target executable
is ONLY getting updated if utility.com updates the local include file.
There are numerous other reasons the target should get updated, e.g.
my_source_file is updated. So, the obvious step, is to include both
descrip.mms and descrip2.mms in the command line, like so:
mms /descrp=(descrip.mms, descrip2.mms)
and we can remove the mms call from descrip.mms:
descrip.mms:
local_include_file DEPENDS_ON global_include_file
RUN UTILITY COM FILE
This way, descrip.mms always runs before descrip2.mms and updates the
local include file if necessary. Then descrip2.mms gets run, and will
update the target executable if the local_include_file has been
updated. Still, this solution was not ideal, for two reasons:
1. I would need to make significant modifications to our build
utility. E.g. if a user wants to build TEST.MMS, I would have to check
the existence of TEST_MESSAGES.MMS.
2. What if the target being built contains many tasks, eg.
COMMON_UTILITIES? This MMS file contains numerous include files, so
what do I put on the command line, just one
COMMON_UTILITIES_MESSAGES.MMS? or do I need to work out each invidual
MMS file that is included? How do I deal with multiple targets on the
command line?
Ideally, I needed to find a way to run this utility from within the
MMS file that was being built. Here's the solution that I arrived at:
Say the task we are building is called 'TEST'. in 'TEST.MMS' we create
two build dependencies, one to update the local include file and one
to update the target executable:
TEST.MMS:
TEST ADDITIONALLY_DEPENDS_ON
$(MMS) $(MMSQUALIFIERS) /descr=test_messages.mms TEST
TEST ADDITIONALLY_DEPENDS_ON TEST.EXE
...
<normal build rules, .obj, .c, etc>
TEST.OBJ DEPENDS_ON TEST.C
TEST.C DEPENDS_ON local_include_file
TEST_MESSAGES.MMS:
TEST DEPENDS_ON local_include_file
local_include_file DEPENDS_ON global_include_file
RUN UTILITY COM FILE
By using 'ADDITIONALLY_DEPENDS_ON' we can make 'TEST' a target twice,
and include different action lines to update it. test_messages.mms
always gets called. Then, the normal build rules for TEST will check
the local_include_file and if it is updated, will rebuild the target
executable. The important thing to note is that by using
ADDITIONALLY_DEPENDS_ON, we can run test_messages.mms but not require
a rebuild of the target executable.
The next step, would be to make test_messages.mms redundant. As far as
I have experimented, it is not possible to include the rules in
test_messages.mms within test.mms.
Well, there you have it... Thanks for your help everyone!
- Next message: Tom Linden: "RE: Gaining control of build dependency..."
- Previous message: Bill Todd: "Re: IBM Beats HP for Computing Deal with Lego"
- In reply to: Tom Linden: "RE: Gaining control of build dependency..."
- Next in thread: Tom Linden: "RE: Gaining control of build dependency..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|