Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
Ilija Kocho <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1921|0 |1 is obsolete| | --- Comment #33 from Ilija Kocho <[email protected]> 2012-11-06 20:54:04 GMT --- Created an attachment (id=1979) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1979) Cortex-M4F Floating Point Support 121106 I think that I got a solution for CFLAGS/LDFLAGS management. The problem was that, as it occurs to me, if several CDL components manipulate a string [by means of !is_substr()/is_substr()] they do it in a concurrent manner. I am not familiar with configtool internal structure but it looked like race conditions... Therefore I decided to move all operations in a single CDL that is CYGBLD_ARCH_CPUFLAGS. Besides working smoothly it also solves the following problems: - Home place for FLAGS related "requires" commands, - Extensibility: New flags can be added in future, - Maintenance: All FLAGS operation on architectural level is consolidated in a single CDL. - Compatibility: No tackling with FLAGS on platform level. Platform need only to implement an interface. Look for example in STM 32 patch (untested in runtime). - Simplicity: I hope so :-) My ability for testing is limited during this and following week, but from what I could see it operates as it should. As I have a feeling that we are approaching our goal I would like to do some shaping work. One question is where is best place to put the tests. They stem from kernel tests, should I place them there or under Cortex-M architecture? So far I only run tests on Kinetis. I would appreciate if somebody tries STM32F4. Regards Ilija -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
