This is the mail archive of the
ecos-bugs@sources.redhat.com
mailing list for the eCos project.
[Bug 1000057] New: define -file can only go to <pkgconf/system.h>
- From: bugzilla at ecoscentric dot com
- To: ecos-bugs at sources dot redhat dot com
- Date: Tue, 21 Oct 2003 16:29:51 +0100 (BST)
- Subject: [Bug 1000057] New: define -file can only go to <pkgconf/system.h>
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000057
Summary: define -file can only go to <pkgconf/system.h>
Product: eCos
Version: CVS
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: low
Component: CDL
AssignedTo: bartv@ecoscentric.com
ReportedBy: jifl@ecoscentric.com
QAContact: ecos-bugs@sources.redhat.com
The CDL documentation states this about the define property:
"The -file option can be used to specify an alternative destination. At the time
of writing the only valid alternative definition is -file=system.h, which will
send the output to the global configuration header file pkgconf/system.h."
This is unduly restrictive. For example in the context of generic drivers versus
specific implementations, the only way they can share "common" options is via
pkgconf/system.h, e.g. for the serial drivers CYGPRI_SER_TEST_CRASH_ID, or
CYGDAT_IO_SERIAL_GENERIC_16X5X_INL.
This is poor because the only packages that actually need to know this
information if the configuration changes is e.g. the generic serial driver, or
the 16x5x driver etc. By putting it in system.h though, almost every file in
eCos needs to be unnecessarily rebuilt.
By relaxing this restriction to allow defines in arbitrary <pkgconf/*.h> files
this would be a lot less intrusive. If there is a concern that you don't want
packages changing arbitrary packages in the system, then we could enforce a rule
that it must be a child influencing a parent package, which seems reasonable
given what I suggest it would solve; but I'm not sure such rules should be
necessary anyway as there isn't really a problem to solve.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.