[
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
