public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jim Seymour <ecosjim@cipher.com>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] CDL define_proc: Unable to put "extern" in an include files
Date: Wed, 30 May 2007 18:04:00 -0000	[thread overview]
Message-ID: <465DBB45.3070802@cipher.com> (raw)

I have a desire to inject an "extern" statement into an include file
generated by one of our CDL files - so I added a "define_proc" block.

Worked like a champ - until the build got to the rule to create
"heapgeninc.tcl" out of heapgen.cpp.

This file is run through the preprocessor and the output is then fed to
Tcl.  My "extern" statement is passed through the preprocessor intact,
so when it gets to Tcl, I get this error:

    invalid command name "extern"

The same problem exists when the target.ld file is built.  My "extern"
statement gets stuffed into that file, so ld fails with a "parse error".

I fixed both problems with a horrible kludge: adding a #define to
heapgen.cpp and then bracketing my extern with a #ifndef.  However, I
hate changing standard eCos files unless it's absolutely necessary.

Anyone know how (or if) I can safely add an "extern" to the generated
include files?

Going back a step...

What I'm trying to do is allow for our system clock speed to be a
run-time variable, instead of a fixed constant.  This means that the
#define's that get generated for CYGNUM_RTC_PERIOD (and the like) will
refer to a global variable.  Without an "extern" statement, these
references will cause a compiler error.

-- 
Jim Seymour, Cipher Systems, Inc., http://www.cipher.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

             reply	other threads:[~2007-05-30 17:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30 18:04 Jim Seymour [this message]
2007-05-30 19:02 ` Andrew Lunn
2007-05-31 19:43   ` Jim Seymour
2007-05-31 21:44     ` Andrew Lunn
2007-05-31 22:20       ` Jim Seymour
2007-06-01  8:54 ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465DBB45.3070802@cipher.com \
    --to=ecosjim@cipher.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).