Use build profile to enable RTEMS cross build

[mark0n]

This allows facilities that do not use RTEMS to get rid of the complexity of building this package's RTEMS dependencies. Set the environment variable DEB_BUILD_PROFILES=pkg.asyn.rtems when compiling to enable the RTEMS build.

[aderbenev]

It still dreads me how Michael mentioned some time ago about RTEMS support complexities and possible deprecation. I certainly can see the point behind the idea; moreover, there were reports that things mostly build just fine for Debian 9 on a condition that all RTEMS stuff is thrown away. But, given that we have quite few RTEMS systems, my perspective on the matter is not single-minded.

This change looks to me as a compromise, to keep RTEMS capacity while tending to those who have no interest in it, which is of course much better than just dropping the support entirely. What I wonder about is how it is to be addressed from the perspective of our build infrastructure (i.e. pbuilder). I suppose I can set DEB_BUILD_PROFILES=pkg.asyn.rtems via hooks in the image. But when more packages will define more profiles, I'll have to include them all to the list - and they all will be defined in the environment for any package built. Doesn't seem too clean to me.

I can think of the following:

• Invert the behavior so that by default RTEMS stuff was built, and then there is a setting to disable it if needed, or
• Make the profile generic so that one setting could be set and used for this and other packages uniformly, or
• Use a more reasonable way to support that in pbuilder rather than passing a long environment variable in hooks. I'd be glad to hear any insights on how it can be done.

[mark0n]

• Inverting the behavior doesn't solve the problem but shifts it to the non-RTEMS users. I was intending to make simple things (building for Linux only) simple. I was also assuming that only a small fraction of people are actually interested in building for RTEMS.
• According to my understanding using a generic build-profile name like DEB_BUILD_PROFILES=rtems as suggested by @mdavidsaver wouldn't conform to Debian's rules.
• I don't think you need to mess with pbuilder's hooks. I was able to build the package by simply setting the environment variable: DEB_BUILD_PROFILES=pkg.asyn.rtems gbp buildpackage -uc -us.

At FRIB I counted ~12 RTEMS-capable packages. Assuming that the number would be in the same order of magnitude at BNL you would need to set ~12 environment variables (which is manageable) or you could come up with some fancy lookup mechanism (e.g. a database that maps a package name to the corresponding build-profile names). Note that both approaches would allow you to enable the RTEMS build only for those packages you actually use with RTEMS.

[aderbenev]

The automated way we have it is dput -> inoticoming -> rebuildd -> pbuilder -> inoticoming -> reprepro. I'll need to somehow propagate the environment variable to the pbuilder image. As I can see now, I could detect the package name in the build command and then conditionally export in pbuilderrc (counts for a fancy lookup mechanism)... that's a mechanical challenge, albeit I'm not very joyful about putting package specifics in configuration files.

I concur on the idea of making simple things simple. It's just we're on the other side of RTEMS barricade :) I guess I can start with asyn to adjust the build process for more differentiation.

[mdavidsaver]

https://wiki.debian.org/BuildProfileSpec#Registered_profile_names

Says that pkg.$sourcepackage.$anything

Can be used whenever the maintainer of $sourcepackage agrees to the use.

As we are the maintainers of the epics-base package, why not use pkg.epics-base.rtems everywhere? This avoids a proliferation of profile names, while respecting the namespace rules.

The automated way we have it is dput -> inoticoming -> rebuildd -> pbuilder -> inoticoming -> reprepro.

If memory serves me, pbuilder looks for $DEB_BUILD_PROFILES in its environment. So I think it should be enough to ensure that $DEB_BUILD_PROFILES is set in the rebuildd processes.

Also, it seems that at some point a --profiles argument appeared.

https://manpages.debian.org/testing/pbuilder/pbuilder.8.en.html

[mark0n]

I'm OK with using pkg.epics-base.rtems for all EPICS packages. @aderbenev please let me know if you want me to make this change.

[aderbenev]

That's a good idea. I can just supply the environment variable to the pbuilder invocation and uniformly enable the profile everywhere it applies. Do I get it right that entries which have no profile defined are built at all times? I.e. then I can just have DEB_BUILD_PROFILES=pkg.epics-base.rtems for everything.

[mark0n]

Yes, items with no profile defined are always build.

I have updated the PR to use pkg.epics-base-rtems.

[mark0n]

I realized that when using a build profile that belongs to another package we need a few Lintian overrides (see additional commit).

[mark0n]

OK, I think I got the Lintian stuff right. I'll update the other packages next week.

[mark0n]

OK, I'm done with all packages. Please review. See epicsdeb/epics-base#14 (comment) for a list of the PRs.

[aderbenev]

With base 3.15.5-2 built for Debian 8, I went down the module dependency chain. For RTEMS dependencies, rtems-epics remains at 3.15.3-7. I figured that should not be a big deal since RTEMS stuff depends on RTEMS stuff anyways. With that, seq and scan have their builds succeeded, but asyn is out of luck. Was mixing versions too bold of an assumption to make?

/usr/bin/powerpc-rtems4.9-g++ -B/usr/powerpc-rtems4.9/mvme2100/lib/ -specs bsp_specs -qrtems     -mcpu=603e -Dmpc603e -Dppc603e                  -DUNIX      -O2 -g -mmultiple -mstring -mstrict-align -g   -Wall       -DMY_DO_BOOTP=NULL -DHAVE_PPCBUG     -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/RTEMS -I../../../include -I/usr/lib/epics/include/compiler/gcc -I/usr/lib/epics/include/os/RTEMS -I/usr/lib/epics/include -I/usr/lib/epics/include/compiler/gcc -I/usr/lib/epics/include/os/RTEMS -I/usr/lib/epics/include        -c testOutputCallback_registerRecordDeviceDriver.cpp
/usr/bin/powerpc-rtems4.9-g++ -B/usr/powerpc-rtems4.9/mvme2100/lib/ -specs bsp_specs -qrtems     -mcpu=603e -Dmpc603e -Dppc603e                  -DUNIX      -O2 -g -mmultiple -mstring -mstrict-align -g   -Wall       -DMY_DO_BOOTP=NULL -DHAVE_PPCBUG     -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/RTEMS -I../../../include -I/usr/lib/epics/include/compiler/gcc -I/usr/lib/epics/include/os/RTEMS -I/usr/lib/epics/include -I/usr/lib/epics/include/compiler/gcc -I/usr/lib/epics/include/os/RTEMS -I/usr/lib/epics/include        -c ../testOutputCallbackMain.cpp
/usr/bin/powerpc-rtems4.9-g++ -B/usr/powerpc-rtems4.9/mvme2100/lib/ -specs bsp_specs -qrtems   -o testOutputCallback -static -L/build/asyn-4.33/lib/RTEMS-mvme2100 -L/usr/lib/epics/lib/RTEMS-mvme2100           -mcpu=603e -Dmpc603e -Dppc603e -u Init /usr/powerpc-rtems4.9/mvme2100/lib/no-dpmem.rel /usr/powerpc-rtems4.9/mvme2100/lib/no-mp.rel /usr/powerpc-rtems4.9/mvme2100/lib/no-part.rel /usr/powerpc-rtems4.9/mvme2100/lib/no-signal.rel /usr/powerpc-rtems4.9/mvme2100/lib/no-rtmon.rel            testOutputCallback_registerRecordDeviceDriver.o testOutputCallbackMain.o    -ltestOutputCallbackSupport -lasyn -ldbRecStd -ldbCore -lca -lCom      -ltecla_r -lbspExt -lm -lrtemsCom -lc -lrtemscpu -lCom -lnfs -lm -lgcc
testOutputCallback_registerRecordDeviceDriver.o: In function `__static_initialization_and_destruction_0':
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:230: undefined reference to `pvar_dset_devLsiEnviron'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:230: undefined reference to `pvar_dset_devLsiEnviron'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:230: undefined reference to `pvar_dset_devSiEnviron'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:230: undefined reference to `pvar_dset_devSiEnviron'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:282: undefined reference to `pvar_int_dbQuietMacroWarnings'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:282: undefined reference to `pvar_int_dbRecordsAbcSorted'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:282: undefined reference to `pvar_int_dbQuietMacroWarnings'
/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100/testOutputCallback_registerRecordDeviceDriver.cpp:282: undefined reference to `pvar_int_dbRecordsAbcSorted'
collect2: ld returned 1 exit status
/etc/epics/configure/RULES_BUILD:201: recipe for target 'testOutputCallback' failed
make[4]: *** [testOutputCallback] Error 1
make[4]: Leaving directory '/build/asyn-4.33/testOutputCallbackApp/src/O.RTEMS-mvme2100'
/etc/epics/configure/RULES_ARCHS:58: recipe for target 'install.RTEMS-mvme2100' failed
make[3]: *** [install.RTEMS-mvme2100] Error 2
make[3]: Leaving directory '/build/asyn-4.33/testOutputCallbackApp/src'
/etc/epics/configure/RULES_DIRS:84: recipe for target 'src.install' failed
make[2]: *** [src.install] Error 2
make[2]: Leaving directory '/build/asyn-4.33/testOutputCallbackApp'
/etc/epics/configure/RULES_DIRS:84: recipe for target 'testOutputCallbackApp.install' failed
make[1]: *** [testOutputCallbackApp.install] Error 2
make[1]: Leaving directory '/build/asyn-4.33'
dh_auto_build: make -j1 LINKER_USE_RPATH=NO USE_RPATH=NO SHRLIB_VERSION=4.33 EPICS_HOST_ARCH=linux-x86_64 CROSS_COMPILER_TARGET_ARCHS=linux-x86_64-debug RTEMS-mvme2100 RTEMS-mvme3100 RTEMS-mvme5500 RTEMS-pc386 returned exit code 2
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

[mark0n]

You need to bump the master-rtems branch of EPICS Base up to 3.15.5.

[aderbenev]

With how master-rtems is "51 commits ahead, 39 commits behind master", I'm not exactly sure how to properly tackle the matter. Upstream import and version bump? Merge from master? Wouldn't want to brutalize the branch. Also interesting that two modules went through all good.

[mark0n]

According to the history we merged master into master-rtems in the past.

[aderbenev]

Built 32/64 bit, base 3.15.5, Debian 8 and RTEMS 4.9 for our repo.