This is the mail archive of the ecos-bugs@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]