How do I adjoin additional #include paths to generated Makefiles in RTW

I thought I'd asked this before, but I've found no trace of it.

I'm implementing an addition to someone else's block-set, to support additional CAN-message manipulation options. This puts me at the mercy of model-building mechanisms I don't control. A lot of support code, which you might expect to be pre-built as a library, is actually built at model-building time, using a header file generated during the building process to configure features like buffer sizes (and remove unwanted code and data).

What I think I ought to be doing is adjoining additional search paths at model-building time to the list of directories in which C headers are sought. Tweaking the way in which the Makefile is generated (or invoked) doesn't sound all that hard, but finding a non-disgusting way to do it has so far defeated me.

I could well be taking entirely the wrong approach: do by all means suggest alternatives. All assistance gratefully received!

addIncludePaths() is (surely?) intended to do what I want, but I've yet to find a place where I can call it successfully.

As an alternative, I tried addCompileFlags(), with similar (non-) results. This call seems not to want to work with '-I' flags, at least, not from any point in the building process where I've been able to add a callback. The documentation shows only a very limited range of flags, but doesn't actually say that any are prohibited. What actually are the rules for addCompileFlags(), and where may it be called? Presumably RTW.BuildInfo is not always available (or is in danger of being discarded and re-generated), and I'd expect it to be locked for quite a bit of the build process.

I could generate or copy the headers into the generated-sources directory, or I could generate a proxy header, which in turn includes the really-intended header by its full path. This is ugly for my own headers, and really silly for MATLAB's own headers, though it is what I am presently doing.

Finally, of course, I could hack the Makefile itself after it's generated, editing the relevant inclusion macros. This in turn makes me too dependent on the Makefile format used by someone else's block-set, which is itself liable to change (and, indeed, differ between different MATLAB versions).

Bernard Leak.

Answer 1

[Kaustubha Govind]

When you say "I'm implementing an addition to someone else's block-set" - do you mean that you are adding/modifying S-function driver block(s)? If so, you should find this documentation useful: Build Support for S-Functions. I personally prefer using the rtwmakecfg.m API described on the page to customize build rules.

[Bernard Leak]

Thanks for the response, but I don't seem to be able to

use it.

I am indeed adding additional S-function blocks, some of

which are drivers and some of which are "abstract"

manipulators of the parts of a CAN message.

The existing block-set's template make-file does NOT

expand the macros I can fill in using rtwconfig.m .

Moreover, the supporting MATLAB code is obfuscated into

p-code, and it checks for modifications of the tmf (and

other things), so I can't patch it. This may well be

related to the apparent failure of addIncludePaths()

(&c.) to work.

I know, I know. The recommended way to not be in this

situation is never to get into it in the first place.