epics-modules / mrfioc2

EPICS driver for Micro Research Finland event timing system devices
http://epics-modules.github.io/mrfioc2/
Other
8 stars 30 forks source link

epicsTypes.h includes to deal with missing epicsUInt type definitions #14

Closed aderbenev closed 6 years ago

aderbenev commented 7 years ago

To make the latest version build for RTEMS (on Debian 7 with base 3.14.12.3-6), I have to add several includes to deal with missing type definitions, e.g.:

In file included from ../../../include/mrfCommonIO.h:102,
                 from ../mrmSeq.cpp:17:
../../../../devlib2/include/os/RTEMS/epicsMMIO.h:51: error: 'epicsUInt16' does not name a type
../../../../devlib2/include/os/RTEMS/epicsMMIO.h:59: error: 'epicsUInt32' does not name a type
../mrmSeq.cpp:389: warning: 'done_SoftSequence' defined but not used
../mrmSeq.cpp:778: warning: 'done_SeqManager' defined but not used

There is evidence that the build is successful with no modifications when using base 3.15.

Furthermore, if building with additional modules (autosave, caputlog, deviocstats), the build fails obscurely, unless DEVLIB2 is moved before all modules in configure/RELEASE. E.g.:

../evr.cpp: In member function ‘virtual std::string EVR::position() const’:
../evr.cpp:61:38: error: ‘const struct epicsPCIDevice’ has no member named ‘slot’
../evr.cpp:62:63: error: ‘const struct epicsPCIDevice’ has no member named ‘slot’
../evr.cpp: At global scope:
../evr.cpp:143:1: warning: ‘done_EVR’ defined but not used [-Wunused-variable]
../evr.cpp:162:1: warning: ‘done_Input’ defined but not used [-Wunused-variable]
../evr.cpp:171:1: warning: ‘done_Output’ defined but not used [-Wunused-variable]
../evr.cpp:188:1: warning: ‘done_Pulser’ defined but not used [-Wunused-variable]
../evr.cpp:195:1: warning: ‘done_PreScaler’ defined but not used [-Wunused-variable]
../evr.cpp:240:1: warning: ‘done_CML’ defined but not used [-Wunused-variable]
../evr.cpp:248:1: warning: ‘done_DelayModuleEvr’ defined but not used [-Wunused-variable]
make[3]: *** [evr.o] Error 1

Those problems might be remedied by using a newer base, but as long as the source is supposed to build with 3.14...

mdavidsaver commented 7 years ago

Those problems might be remedied by using a newer base, but as long as the source is supposed to build with 3.14...

I suppose the issue is that "3.14" is a wide range (more than a decade). My testing now is with the 3.14 dev branch (aka 3.14.12.6+). However, the documentation still claims >=3.14.10, which you've shown to be not the case. I'll look into this.

../evr.cpp:61:38: error: ‘const struct epicsPCIDevice’ has no member named ‘slot’

This means you need a newer devlib2. >= 2.9.

There is evidence that the build is successful with no modifications when using base 3.15.

https://travis-ci.org/epics-modules/mrfioc2

aderbenev commented 7 years ago

In all cases I've built with the devlib2 version freshly checked out from epics-modules/devlib2 - as it is noted necessary in mrfioc2 changelog (and I managed to read that much). That 'slot' error is nicely fixed by rearranging module order in configure/RELEASE, a solution I wouldn't expect to be sufficient in case of a wrong library version.

For evidence, I meant that sources probably were manually built with manually built base (I should verify that); travis is an extra proof of course, but as I sometimes find what builds great in one environment requires great investigation in another, the sad reality is changes applied. I certainly concur on the notion that all can benefit from more recent environment versions, so observations described herein are more like FYI.

aderbenev commented 7 years ago

Okay, couple of things on obscurity. First, it appears that if environment as such that modules and base are installed somewhere and this location is mentioned and precedes location of actial new devlib2 in RELEASE, it will override the whatever DEVLIB2=... path. That is, I had epics-devlib2-dev package installed so it was used during the build process instead of what I intended to use. In total correspondence with Michael's comment, my build was effectively using the wrong version of devlib2 - not like it was obvious to me right away however, given that I set the DEVLIB2 path specifically.

Second funny thing was that mrf.obj file was not generated despite having USE_GESYS=YES. Eventually I figured out that if in configure/CONFIG_SITE I have trailing tabulation:

USE_GESYS=YES\<tab>

the string will be ignored. While of course there is no reason to have trailing tabulations, it is no reason for that case not to work - at least because the cause is invisible.

mdavidsaver commented 6 years ago

@aderbenev Can you close/cancel this pull request if it isn't necessary?

aderbenev commented 6 years ago

Nothing of cosmic significance here, closing.