Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
--- Comment #11 from Ilija Kocho <ili...@siva.com.mk> 2012-06-28 08:40:46 BST --- Hi Jifl Here I revisit the CFLAGS (In reply to comment #10) > > - Here's a possible outline of a simplification. What do you think? > > cdl_option CYGHWR_HAL_CORTEXM_FPU_FLAGS { > > display "FPU build flags" > > calculated { (CYGHWR_HAL_CORTEXM_FPU ? " -mfloat-abi=hard" : "" ) . > > (CYGINT_HAL_CORTEXM_FPV4_SP_D16 ? " -mfpu=fpv4-sp-d16" : "" ) } > > } > > requires is_substr(CYGBLD_GLOBAL_CFLAGS, CYGHWR_HAL_CORTEXM_FPU_FLAGS ) > > requires is_substr(CYGBLD_GLOBAL_LDFLAGS, CYGHWR_HAL_CORTEXM_FPU_FLAGS ) > > requires { !CYGHWR_HAL_CORTEXM_FPU implies > > !is_substr(CYGBLD_GLOBAL_CFLAGS, > > "-mfpu=fpv4-sp-d16") && !is_substr(CYGBLD_GLOBAL_CFLAGS, > > "-mfloat-abi=hard") } > > requires { !CYGHWR_HAL_CORTEXM_FPU implies > > !is_substr(CYGBLD_GLOBAL_LDFLAGS, > > "-mfpu=fpv4-sp-d16") && !is_substr(CYGBLD_GLOBAL_LDFLAGS, > > "-mfloat-abi=hard") } > > Since you ask me, I would get rid of is_substr(). Something like this: > > cdl_option CYGHWR_HAL_CORTEXM_FLOAT_ABI_FLAG { > flavor data > no_define > display "Float ABI flag" > calculated { CYGHWR_HAL_CORTEXM_FPU ? " -mfloat-abi=hard" : "" } > } > > cdl_option CYGHWR_HAL_CORTEXM_FPU_FLAG { > flavor data > no_define > display "FPU build flags" > calculated { (CYGHWR_HAL_CORTEXM_FPU && CYGINT_HAL_CORTEXM_FPV4_SP_D16) > ? > " -mfpu=fpv4-sp-d16" : "" } > } > > Ditto for -mcpu=cortex-m3/m4 (CYGHWR_HAL_CORTEXM_CPU_FLAG). > > Then we concatenate all these in CYGBLD_GLOBAL_CFLAGS. > > cdl_option CYGBLD_GLOBAL_CFLAGS { > display "Global compiler flags" > flavor data > no_define > default_value { CYGBLD_GLOBAL_WARNFLAGS . CYGHWR_HAL_CORTEXM_CPU_FLAG . > " -mthumb -g -O2 ffunction-sections -fdata-sections -fno-rtti > -fno-exceptions" . > CYGHWR_HAL_CORTEXM_FLOAT_ABI_FLAG . CYGHWR_HAL_CORTEXM_FPU_FLAG } > } > I found out that this requires CYGBLD_GLOBAL_CFLAGS to be *calculated* instead of *default_value*. I assume that it is not flexible enough so I revoke it. Regarding your outline it looks nicer than the one I posted in the patch. However it leaves some unresolved conflicts when I try to change code generation by clicking the subject controls in configtool. Actually I came to the construction from the submitted patch after pretty much experimenting and my criterion was: least clicks that produce unresolved conflicts. To explain what I mean, here's one example: 1. Create a configuration with "Freescale Kinetis TWR-K70F120M" default template. 2. Deselect Cortex-M4 code. Configtool shall report unresolved conflicts. (You can make it easier to configtool if you deselect Hardware FPU prior to deselecting Cortex-M4). This is AFAICT the only case that produces unresolved conflict for present CDL construction. Other combinations that I have tried have more cases. I'm not much familiar with CDL engine, but from my experience I would say that it is easier to corner configtool to resolve the conflicts if expressions are constants (rather than variables). Cheers 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.