I think the key (if it is going to work –
it’s possible that MBS doesn’t support what you are trying to do)
is to get the outputType for the .h file that is generated defined correctly. Make
sure that you take a look at the various mechanisms for letting MBS know the name
of the output file and get that correct.
* The priorities for
determining the names of the outputs of a tool are:
* 1. If the
tool is the build target and primary output, use artifact name & extension
-
*
This case does not apply here...
* 2. If an
option is specified, use the value of the option
* 3. If a
nameProvider is specified, call it
* 4. If
outputNames is specified, use it
* 5. Use the
name pattern to generate a transformation macro
*
so that the source names can be transformed into the target names
*
using the built-in string substitution functions of
<code>make</code>.
The other approach is to take an MBS
generated makefile that almost does what you want and see what you have to do
with it to get make to build your project properly. Remember that the MBS
is limited by what make can handle. Once you figure out what you need,
then you may be able to modify your inputTypes and outputTypes to get MBS to
generate it. Or, maybe you have found a case that MBS can’t
currently handle…
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Delicia
Sent: Thursday, September 28, 2006
7:27 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Re: InputOrder
element
Thanks for the info, Leo.
Earlier, I had tried sorting out the tool invocation order
by playing around
with the "buildVariable" attribute of inputType
& outputType elements.
Didn't have much luck, though.
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Sep 2006 08:15:46 -0700
From: "Treggiari, Leo" <leo.treggiari@xxxxxxxxx>
Subject: RE: [cdt-dev] InputOrder element
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Message-ID:
<ACB56C676BEBB44DB528061186E73A67015D2C63@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
The InputOrder element is not implemented, and in any case, I don't
think it would help you. It is meant to support ordering of the inputs
to a tool on a command line.
Regarding the tool invocation order, MBS generates a makefile and make
determines the order based upon the dependencies identified in the
makefile. The target tool tells make what output(s) make needs to
ensure are up to date. It is then up to make to determine what tools
need to run and in what order. In order to ensure that one tool runs
before another, a tool has to "consume" the output of the other tool.
This is done through input and output types.
Leo
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Delicia
Sent: Wednesday, September 27, 2006 2:55 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] InputOrder element
Hi,
For my toolchain (built on MBS 3.0.2), I have a requirement where a
tool should be invoked first (before the C compiler tool).
As I understand, the order of invoking tools is primarily dependent on
the order/sequence of inputType (s) to the target tool (linker in this case).
>From what I read, the "InputOrder" element should be useful.
So, I added an inputType element (ordered 1st) for the linker (with
build variable=PSM_FILE, which matches that of the outputType for the
bool tool).
To this, I added an inputOrder element with:
path=$(PSM_FILE)
excluded=true
But this results in strange behaviour.
Building my project stops at an empty subdir.mk file.
Am I using the "inputOrder" element in the correct manner?
Or is it that support for this element is not present in 3.0.2?
I currently work around this problem by adding $(PSM_FILE) an
'additionalDependency' for the 'C compiler' inputType.
But this is not at all optimal, since it results in rebuilding *all* C
sources for a change in $(PSM_FILE), even if the corresponding .d didn't deem
it necessary.
Thanks,
Delicia.
