2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: CaSe-IndepeDent Menu SEARches? |
From: | Ralph Lange via Core-talk <core-talk at aps.anl.gov> |
To: | EPICS Core Talk <core-talk at aps.anl.gov> |
Date: | Thu, 4 Feb 2021 19:20:07 +0100 |
On Feb 4, 2021, at 10:58 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wroteWe should provide linting service on the EPICS web page. Would generate nice data of what EPICS features people are using. (And their most common errors.)
Not convinced; a web-page wouldn’t know about external record types, device support or locally added scan rates or breakpoint tables, amongst other things. That’s why I think it has to be local functionality. A linter would also need to know which DBD file to use for each DB file it’s checking. We’d have to put something into the build system to specifically request running dbLint against each DB file at build time, and it would have to ignore unexpanded macros in the file so there will still be errors that only the IOC would see.
And of course a dbLint program would be of lesser use to sites like PSI or ESS that don’t generate an IOC-specific DBD file anyway, only their IOCs know the complete collection of DBD fragments that are being loaded there. A linter could be taught to ignore unknown record types (or even to ignore just the fields in one that are not found in dbCommon) but the DTYP, SCAN and LINR fields would still generate false positives.