subdivide large .ttcn files for faster dev cycle

I've raised this some years ago, then had gotten the response that our .ttcn files should grow to any size, and we should fix the tooling instead or buy a faster computer. But I'm still having the annoyance when working with our ttcn that even changing a tiny constant will trigger a longish recompilation. It looks like it is dividing a .ttcn into parts, and keeps recompiling *all* of the parts. (not always all of the parts, but usually it is clumsy about compiling more than would be logically required from my POV.) It looks like this: + make -j 5 Creating dependency file for HNBGW_Tests_part_6.cc Creating dependency file for HNBGW_Tests_part_5.cc Creating dependency file for HNBGW_Tests_part_4.cc Creating dependency file for HNBGW_Tests_part_3.cc Creating dependency file for HNBGW_Tests_part_2.cc Creating dependency file for HNBGW_Tests_part_1.cc Creating dependency file for HNBGW_Tests.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests.o HNBGW_Tests.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_1.o HNBGW_Tests_part_1.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_2.o HNBGW_Tests_part_2.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_3.o HNBGW_Tests_part_3.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_4.o HNBGW_Tests_part_4.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_5.o HNBGW_Tests_part_5.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_6.o HNBGW_Tests_part_6.cc env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests.so HNBGW_Tests.o env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_3.so HNBGW_Tests_part_3.o env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_4.so HNBGW_Tests_part_4.o env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_2.so HNBGW_Tests_part_2.o env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_1.so HNBGW_Tests_part_1.o HNBGW_Tests_part_5.cc: In function ‘OCTETSTRING HNBGW__Tests::f__gen__one__compl__l3(const Compl3Type&, const MobileL3__CommonIE__Types::MobileIdentityLV_template&, const INTEGER&)’: HNBGW_Tests_part_5.cc:2130:1: warning: control reaches end of non-void function [-Wreturn-type] 2130 | } | ^ env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_5.so HNBGW_Tests_part_5.o env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_6.so HNBGW_Tests_part_6.o I want a fast dev cycle, and the ttcn dev cycle is slow: after a tiny edit, the CPU spools up and the fan goes for a whole while, and I get bored and irritated. When I'm on a train ttcn compilation drains the battery... My local workaround was to create a second file, like BSC_Tests_2.ttcn, with only my new test in it. Then compilation cycles are rapid. But that requires modifying all sorts of s/private/friend and even only moving the code is another annoyance. If I want to apply CR, I won't move it back and forth, so usually I end up with two copies and get confused. So my local workaround isn't working out very well. Why am I writing this here? Because I would like to request that we start subdividing our ttcn into smaller compilation units, not as my local workaround but permanently in our upstream. Please? ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Siemensstr. 26a * 10551 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte