[ Cc'ing *all* affected packages. Noisy, but all parties involved should be aware of the progress. ]
Helmut Grohne wrote... > I'm not sure that adding our own confgen is maintainable in the long > run. We already have very many build systems in Debian. We've learned > the hard way that supporting many different build and packaging tools is > expensive. Nowadays, most packages use debhelper and that kind of > centralization bears benefits in modifiability. So I wonder whether > outright replacing confgen usage (effectively reimplementing the build > system for <= 15 packages) would be more maintainable in the long run. > Most likely, that would make cross building just work. On the other > hand, we'd have to extend the prospective confgen to support that use > case. > > I'm suggesting that rewriting all those build systems using one of the > standard tools (e.g. autotools, cmake, meson, maybe not qmake, ...) > could mean less work. Switching to e.g. cmake means a one-time more-or-less complex manual transition but afterwards the packaging should be in a sane state for quite some time. After thinking about this for a few days I agree this is the sanest way to go. For the current build system, there are already some extra kludges (check out debian/rules if you really want to), and setting up a confgen emulation, probably as a debhelper extension ... while this was a faszinating project, it would certainly eat up some ressources to set up and to maintain. Also, since confgen upstream (see below) described the program as a hack and I subscribe to that point of view, it's really better to look forward, even for these old packages. Still I assume this will be my job - however, the changes will go beyond a sound NMU size. So I'll send out patches, and eventually go the package salvaging way. For two packages, I did the migration already. Seems it's not very difficult, but worth it¹. Most time was spent in identifying the meaning of the 29 symbols found in the MCONFIG.in files. Second-biggest task is learning cmake, but this has been on my agenda for some time anyway :) Also, good news, old upstream answered my question *and* provided a copy of confgen - which will help a lot trying to understand the internals. If someone more experienced in cmake wants to help, please get in touch. Otherwise, allow me until end of November to create the fixes - there is something called "real life" out there. Still my plan is to salvage *all* packages. The expensive part is the thing called "setup fee" somewhere else, and I'm mostly done with it. Cheers, Christoph ¹ For example for bsd-finger: CMakeLists.txt: | cmake_minimum_required (VERSION 3.7) | project (bsd-finger) | | set(BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin") | set(MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man") | | add_subdirectory(finger) | add_subdirectory(fingerd) finger/CMakeLists.txt: | file(GLOB SRCS "*.c") | add_executable( | finger | ${SRCS} | ) | install( | TARGETS finger | DESTINATION ${BIN_DIR} | ) | install( | FILES finger.1 | DESTINATION ${MAN_DIR}/man1/ | ) fingerd/CMakeLists.txt: | file(GLOB SRCS "*.c") | add_executable( | in.fingerd | ${SRCS} | ) | install( | TARGETS in.fingerd | DESTINATION ${SBIN_DIR} | ) | install( | FILES fingerd.8 | DESTINATION ${MAN_DIR}/man8/ | RENAME in.fingerd.8 | ) debian/rules: | #!/usr/bin/make -f | | %: | dh $@ --buildsystem=cmake ... and several more files in debian/ shortened or entirely removed.
signature.asc
Description: PGP signature