From karl at freefriends.org Tue Oct 2 03:58:10 2018 From: karl at freefriends.org (Karl Berry) Date: Tue, 2 Oct 2018 01:58:10 GMT Subject: [tlbuild] VERBOSE=1 -> show build-log.txt Message-ID: <201810020158.w921wAUa014267@freefriends.org> A contributor on the automake mailing list reported that make check VERBOSE=1 cats test-suite.log to stdout if failure, as we have wanted (especially) for the autobuilds on inaccessible systems. http://lists.gnu.org/archive/html/automake/2018-09/msg00015.html As far as I can tell from the sources, that is all that VERBOSE=1 does (not the best choice of variable name). So I've changed the TL ./Build script to automatically do that (r48808). If for some reason you don't want it, you can set the envvar TL_MAKE_VERBOSE to the empty string (or a space, or whatever) before calling that. If you don't use the Build script, you may want to add this to your build procedures. Happy compiling! -k P.S. Most of the dvipdfm-x tests failed for me, so I got to experience the new behavior first hand. I'll look at that tomorrow if need be, though most likely Akira will get there first. From mojca.miklavec.lists at gmail.com Mon Nov 12 22:44:40 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Mon, 12 Nov 2018 22:44:40 +0100 Subject: [tlbuild] LuaJIT on OpenBSD In-Reply-To: References: Message-ID: Hi, Replying to myself after quite a while ... When building luajittex on OpenBSD with clang one apparently needs something like LDFLAGS="-lc++abi -lpthread" to get the missing functionality. I suspect that in TeX Live LuaJIT was built in pure C, while in LuaTeX repository it might have been linked with some other C++ libraries (blind guess). When LuaTeX got rid of all C++ libraries, LuaJIT would no longer compile there either. Mojca On Sun, 1 Apr 2018 at 10:50, Mojca Miklavec wrote: > > Hi, > > Before the switch to C++11 and when compiling with gcc, luajitex > compiled on OpenBSD. Now I switched to clang and I'm getting undefined > references: > > /bin/sh ./libtool --tag=CC --mode=link clang -Wimplicit > -Wreturn-type -Wdeclaration-after-statement -Wno-unknown-pragmas -g > -O2 -export-dynamic -o mfluajit mfluajitdir/mfluajit-mfluajitextra.o > libmfluajit.a lib/lib.a /path/to/Work/texk/kpathsea/libkpathsea.la > window/libwindow.a -L/usr/X11R6/lib -lSM -lICE -lXext > -L/usr/X11R6/lib -lX11 /path/to/Work/libs/luajit/libtexluajit.la -lm > libtool: link: clang -Wimplicit -Wreturn-type > -Wdeclaration-after-statement -Wno-unknown-pragmas -g -O2 -o mfluajit > mfluajitdir/mfluajit-mfluajitextra.o -Wl,-E libmfluajit.a lib/lib.a > /path/to/Work/texk/kpathsea/.libs/libkpathsea.a window/libwindow.a > -L/usr/X11R6/lib -lSM -lICE -lXext -lX11 > /path/to/Work/libs/luajit/.libs/libtexluajit.a -lm > -Wl,-rpath,/usr/X11R6/lib -Wl,-rpath,/usr/X11R6/lib > mfluajitdir/mfluajit-mfluajitextra.o: In function `calledit': > ../../../texk/web2c/lib/texmfmp.c:2492: warning: warning: sprintf() is > often misused, please use snprintf() > lib/lib.a(openclose.o): In function `open_input': > ../../../../texk/web2c/lib/openclose.c:236: warning: warning: strcpy() > is almost always misused, please use strlcpy() > /path/to/Work/texk/kpathsea/.libs/libkpathsea.a(libkpathsea_la-concat.o): > In function `concat': > ../../../texk/kpathsea/concat.c:32: warning: warning: strcat() is > almost always misused, please use strlcat() > /path/to/Work/libs/luajit/.libs/libtexluajit.a(lj_err.o): In function > `lj_err_unwind_dwarf': > ../../../libs/luajit/LuaJIT-src/src/lj_err.c:236: undefined reference > to `_Unwind_GetCFA' > ../../../libs/luajit/LuaJIT-src/src/lj_err.c:254: undefined reference > to `_Unwind_DeleteException' > > I know we are not shipping binaries, so this in not critical, but I'm > just curious if anyone has any idea. > > Thank you, > Mojca From karl at freefriends.org Sat Dec 22 15:44:26 2018 From: karl at freefriends.org (Karl Berry) Date: Sat, 22 Dec 2018 07:44:26 -0700 Subject: [tlbuild] failure to propagate TL_CONFIGURE_ARGS completely In-Reply-To: Message-ID: <201812221444.wBMEiQMT031526@freefriends.org> Hi Nelson - back on this report from 2016 (sorry): https://tug.org/pipermail/tlbuild/2016q2/003548.html However, that option [--build] supplied in the environment like this: env TL_MAKE=/usr/local/bin/gmake \ TL_CONFIGURE_ARGS=--build=x86_64-unknown-freebsd10.2 \ texlive-20160504/source/Build fails to propagate to the freetype2 configure script: I changed freetype2/configure.ac to pass a --build argument to the freetype (sub)configure if specified (r49476). Before, --build was only passed if --host was also specified. It seems to me that in principle all arguments from configure should be passed, but I'm guessing peb had a good reason to do it this way, so went with the minimal change. I could not find any other setups with this particular problem, though I certainly could have missed it. Let me know if this problem persists ... --thanks, karl. From karl at freefriends.org Sun Dec 23 00:27:56 2018 From: karl at freefriends.org (Karl Berry) Date: Sat, 22 Dec 2018 16:27:56 -0700 Subject: [tlbuild] dvipdfm-x issues In-Reply-To: Message-ID: <201812222327.wBMNRuf3024167@freefriends.org> Hi Nelson - back on your mail from May 2016 (sorry): https://tug.org/pipermail/tlbuild/2016q2/003535.html When I examine texk/config.log and texk/dvipdfm-x/log on OpenSUSE 11 ... ./libtool: line 7475: cd: ${exec_prefix}/lib/x86_64-pc-linux-gnu: No such file or directory I believe this is the same problem you reported wrt centos6 on March 1, 2018. I replied to it here, suggesting configure --libdir=/usr/local/lib as the cleanest fix: https://tug.org/pipermail/tlbuild/2018q3/004294.html I don't know if you tried that or if it works. I hope so. FWIW, I logged in to your osuse11 machine (osuse.vm) and was able to build all the non-C++11 programs like this (~karl/bin/mybuild on that machine), but without trying to use any local libraries or compilers: PATH=/usr/bin:/bin cd /tl/source rm -rf libs/icu libs/poppler libs/graphite2 texk/dvisvgm # or configure fails ./Build \ -g \ -C \ --disable-xetex \ --disable-luatex \ --disable-luajittex \ --disable-luatex53 \ --disable-dvisvgm \ --disable-bibtexu \ --disable-upmendex \ --disable-poppler \ --without-system-icu \ --without-system-graphite2 \ --without-system-poppler \ --enable-native-texlive-build I realize this is not reproducing your exact situation, but it's what I've got. Sorry. (I think you may be just about the only person on the planet trying to use many locally-compiled libraries.) It really would be nice if we could get builds to work pretty much anywhere Yes, it certainly would. I am only one person and can only do so much, as can be seen by the dates on these messages. Pretty much every configure failure has to be investigated from scratch, on a system of the right type, all the way to the bitter end. So just reproducing such problems is nontrivial. I know everyone does what they can. All I can say is that it also "would be nice" if other contributors could get to the point of finding fixes for particular configure failures. It's all just shell scripts, so ultimately all is visible. I know automake/autoconf are seen as painful. I don't disagree, but I believe it's because software configuration is inherently, unavoidably, horribly painful nowadays. I am not aware of any system that could replace it for TL's situation, with many heterogenous packages coming from many different sources. (CMake is not even remotely flexible enough.) The only real "fix" I can see is no longer creating binaries in the upstream TeX Live, and leaving it to distros and others. I don't think that's the desired outcome yet. So we trudge on as best we can ... --best, karl. From mojca.miklavec.lists at gmail.com Sun Dec 23 07:11:17 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 23 Dec 2018 07:11:17 +0100 Subject: [tlbuild] CMake Message-ID: ned., 23. dec. 2018 00:28 je oseba Karl Berry napisala: > > I know automake/autoconf are seen as painful. I don't disagree, but I > believe it's because software configuration is inherently, unavoidably, > horribly painful nowadays. I am not aware of any system that could > replace it for TL's situation, with many heterogenous packages coming > from many different sources. (CMake is not even remotely flexible > enough.) > What are the major drawbacks / concerns / missing functionality? The quality of FindFoo? I thought it was just lack of manpower combined with complexity of the tree preventing us from switching to CMake or Meson. (Ability to get a decently recent version of either build system on ancient boxes is yet another thing of course, with ninja not even working on some archs.) Mojca > -------------- next part -------------- An HTML attachment was scrubbed... URL: From preining at logic.at Sun Dec 23 08:10:05 2018 From: preining at logic.at (Norbert Preining) Date: Sun, 23 Dec 2018 16:10:05 +0900 Subject: [tlbuild] CMake In-Reply-To: References: Message-ID: <20181223071005.GA11314@bulldog.preining.info> Hi Mojca, as one who has recently written a autoconf/automake based system, which is just plain incompatible with how github releases work, and then also built a meson system, I agree with your feeling, and myself I would be happy to see something different. BUT ... Karl is completely right - many different packages that needs inclusion do you want to write meson/cmake for all the libs/progs etc that are actually developed outside of TL and mostly come with auto* build systems? - man power I think if someone starts a meson based system that would be great, and it could be included in the TL sources without interference of file names. ANyone having the time, please go ahead. But I doubt. - old systems esp meson, but also cmake are simply a PITA to get on older systems So as much as I would like to see a more simple build system, I think for now auto* is still the best/stable way to go. But, if someone wants to work on a cmake or meson system that does not interfere with the current status, (s)he is heartly welcome I would say. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From preining at logic.at Sun Dec 23 08:14:55 2018 From: preining at logic.at (Norbert Preining) Date: Sun, 23 Dec 2018 16:14:55 +0900 Subject: [tlbuild] CMake In-Reply-To: <20181223071005.GA11314@bulldog.preining.info> References: <20181223071005.GA11314@bulldog.preining.info> Message-ID: <20181223071455.GB11314@bulldog.preining.info> On Sun, 23 Dec 2018, Norbert Preining wrote: > But, if someone wants to work on a cmake or meson system that does not > interfere with the current status, (s)he is heartly welcome I would say. I forgot - my preference would be for meson. I *hate* cmake. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 From mojca.miklavec.lists at gmail.com Sun Dec 23 11:27:58 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Sun, 23 Dec 2018 11:27:58 +0100 Subject: [tlbuild] CMake In-Reply-To: <20181223071005.GA11314@bulldog.preining.info> References: <20181223071005.GA11314@bulldog.preining.info> Message-ID: On Sun, 23 Dec 2018 at 08:10, Norbert Preining wrote: > > Hi Mojca, > > as one who has recently written a autoconf/automake based system, which > is just plain incompatible with how github releases work, and then also > built a meson system, I agree with your feeling, and myself I would be > happy to see something different. I would like to see support for either system as well. In particular this could have simplified Windows builds (and hopefully not break cross-compiling builds too much). > BUT ... Karl is completely right I'm still waiting for the answer about what the real limitations are. > - many different packages that needs inclusion > do you want to write meson/cmake for all the libs/progs etc that are > actually developed outside of TL and mostly come with auto* build > systems? Well, this counts as "lack of manpower" in my dictionary :) (The answer would be "Yes", of course.) This is not a REAL limitation, just a lot of work that needs to be done at some point. (I don't want to know how many hours Akira has spent on writing and maintaining visual studio project files to keep W32TeX running. And yes, I believe he had to write a separate project file for every single dependency. That was certainly orders of magnitude more work than one with equivalent level of expertise would need to invest into CMake or meson definitions.) Both meson and recent versions of CMake can natively read .pc files for the sake of finding external dependencies, but of course this doesn't scale too well for Windows, so if we would want to do it right, we would need to write all the missing support for all the packages that we ship with the project (not 100% how to do it right for external dependencies). On the plus side, if well written, either CMake or meson support could eventually be included upstream, benefitting everyone else outside of the TeX community. We could start with LuaTeX for example. Something that's still complex enough, actively maintained, but doesn't have **too** many dependencies. > - man power > I think if someone starts a meson based system that would be great, > and it could be included in the TL sources without interference of > file names. ANyone having the time, please go ahead. But I doubt. Yes, we would need to have two systems running in parallel (for at least a couple of years). There's no reason to remove autotools support even if someone steps up and adds support for a new build system. > - old systems > esp meson, but also cmake are simply a PITA to get on older systems (This does count as a real limitation to me.) I have no idea how many platforms/architectures are covered by ninja, but certainly there are lots of exotic ones which are not. And I have absolutely no idea how difficult it is to install python 3 on a random old box. Here's a list of CMake versions that come with some OSes: https://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html CMake now requires C++11 which lead to quite some bootstrapping headaches in MacPorts on older OSes (clang requires CMake to build, and CMake requires C++11 support which can only be achieved by getting a newer compiler first; the workaround is using gcc for bootstrapping, but ...). However we require C++11 for other packages in TeX already, so the really old systems are out of question already. Other than C++11 requirement, is CMake really so much probelmatic to install on older systems? Except of course the pain to have to do that in the first place as opposed to simply running ./configure and getting it work out of the box? The macOS doesn't ship with CMake for example, so one needs to install it manually or via a package manager in any case. It doesn't ship with python3 or ninja either. (I wonder if the existence of package managers on mac just removed pressure from Apple to include some reasonable tools in their OS, or if they simply don't care about developers at all.) > So as much as I would like to see a more simple build system, I think > for now auto* is still the best/stable way to go. > > But, if someone wants to work on a cmake or meson system that does not > interfere with the current status, (s)he is heartly welcome I would say. Definitely if we find sufficient workforce to work on this (I'm willing to spend some time, but there's absolutely no way I would manage to understand it all and do it all, and if I only do 10% of the work, that's equal to nothing). > I forgot - my preference would be for meson. I *hate* cmake. When meson came out / when I heard of it, I was totally enthusiastic :) :) :) I probably spent two days trying to get cross-compilation to work, and failed. Then I did the same in meson (while writing my first project ever) in probably half an hour. I tried to suggest the usage of meson in my company, but my idea was rejected with a pointer to https://www.rojtberg.net/1481/do-not-use-meson/ After listening to quite some "modern CMake" talks I agree that version 3+ is "light-years" better than the old approach, even if the syntax is still weird. I have yet to experience how "modern FindFoo.cmake" works. It was absolutely unbearable from the package management perspective in the past, and I gave up trying to patch those Find packages years ago (I didn't try recently). I absolutely hated that every project had to reinvent the wheel writing custom and totally buggy FindFoo-s. Other concepts now make much more sense to me than they did in the past, I assume that support for cross-compilation is meanwhile better. Another thing I hate with CMake is that unless the authors hardcoded the knowledge about the compiler at hand into the "internal CMake know-it-all about compilers", most of the stuff simply won't work. In contrast to autotools where each feature is tested for separately, CMake "knows it all" and hardly ever tests for stuff. In MacPorts this is a serious issue since we are building our own version of clang on top of what Apple ships by default, and CMake has absolutely no idea what features that compiler has. I think that CMake also supports some kind of tests for features, but I never tested that. I recently asked one package author to modernize the CMake in his super small project, but he said this was no option as he had to support older systems which don't yet have a recent enough version of CMake installed (at which point you loose all the benefits). Probably the most painful part of CMake is that if you google for solutions to your questions / problems nowadays, you'll get super highly-ranked wrong (i.e. outdated) answers on StackExchange more than 90% of the time. So one needs to read a book or two first before starting to write something. >From the point of view of treating bug reports: meson is still in a bit of a beta phase, there are a number of issues (until a few months ago it was literally useless on mac), but they do respond very quickly (last time I checked it was mainly one developer + a few helping out a bit though). CMake didn't fix any single bug of those I reported (you cannot even compile it on OS X 10.7 for example, for a long while it was impossible to compile fortran project on mac until gcc decided not to throw "unknown flag" errors on "-arch i386" any longer), and when they switched to a new bug tracker, they simply closed all reports and asked you to resubmit if you still thought it was relevant. (I started having warm feelings for CMake last week when I figured out how CUDA support worked literally out of the box, and three lines of code replaced probably hours of manual fiddling of project files.) Meson is a really nice and clean language, I like the syntax a lot more than CMake's. From the perspective of momentum, I do fear in a way that it might get "eaten up" by CMake in a similar way as mercurial was "defeated" by git (not comparing features here, just frequency of use), meaning that lack of manpower in one project could no longer cut it at some point, but I cannot predict the future. If build system of TeX Live was rewritten, I'm relatively ambivalent about the choice of the tool. Mojca From karl at freefriends.org Mon Dec 24 01:08:30 2018 From: karl at freefriends.org (Karl Berry) Date: Sun, 23 Dec 2018 17:08:30 -0700 Subject: [tlbuild] CMake In-Reply-To: Message-ID: <201812240008.wBO08UpP013093@freefriends.org> np> So as much as I would like to see a more simple build system, Building TL will never, ever, be simple. Our biggest problem is that we create binaries meant to be widely distributed and used on lots of old systems. This goes against the grain of the rest of the free software world, which, almost invariably, have packages releasing sources; then distros and other such packagers put together the binaries, which are meant to run only on specific os/hardware combinations. Thus, we have to deal with the latest sources on the oldest systems -> ugliness all around. mm> I'm still waiting for the answer about what the real limitations are. I don't have a technical list (despite my previous implication, sorry). I had never heard of meson before now, and my tiny bit of experience with cmake, as a user, has been entirely negative. Despite my ignorance, nothing in your mail or in what I've read makes me think that changing is a good idea. What I know for sure is that an awful lot of time has been invested in the current setup. I just have a failure of imagination as to how the current setup, with all its options (which are there for a reason, so need to be available) could be supported in cmake or meson or anything else. The bottom line for me is that if there is any impetus to switch, the work will have to be done by someone other than me, and I will no longer work on configuration. I just can't do it. --best, karl. From mojca.miklavec.lists at gmail.com Mon Dec 24 10:48:56 2018 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Mon, 24 Dec 2018 10:48:56 +0100 Subject: [tlbuild] CMake In-Reply-To: <201812240008.wBO08UpP013093@freefriends.org> References: <201812240008.wBO08UpP013093@freefriends.org> Message-ID: On Mon, 24 Dec 2018 at 01:08, Karl Berry wrote: > > Building TL will never, ever, be simple. You mean maintaining the build system or actually running the builds? > Our biggest problem is that we create binaries meant to be widely > distributed and used on lots of old systems. This goes against the grain > of the rest of the free software world, which, almost invariably, have > packages releasing sources; then distros and other such packagers put > together the binaries, which are meant to run only on specific > os/hardware combinations. Thus, we have to deal with the latest sources > on the oldest systems -> ugliness all around. This is precisely what makes TeX Live so awesome, most other projects are super painful to build outside of a package manager, having to have all the dependencies sorted out etc. Eventually every package manager applies a bunch of patches to be able to build one particular piece of software. In case of TeX Live we try to keep those patches ourselves, as much as possible. But I don't immediately see additional / added complications from that fact alone. Yes, the sources are often more complicated than they need to be if you need to keep sources compatible with Solaris and *BSD and Alpha and ... It's hardly ever used in CMake, but both CMake and Meson also support checks for certain features, in a similar way as it's done by ./configure. > mm> I'm still waiting for the answer about what the real limitations are. > > I don't have a technical list (despite my previous implication, > sorry). I had never heard of meson before now, and my tiny bit of > experience with cmake, as a user, has been entirely negative. > > Despite my ignorance, nothing in your mail or in what I've read makes me > think that changing is a good idea. What I know for sure is that an > awful lot of time has been invested in the current setup. I would not suggest changing. At least not in some short term. Merely trying to get a parallel system working and improved over time, and see whether we could get it working. But it's an awful lot of work anyway (not that maintaining both Visual Studio projects and autofoo magic is any less time demanding, except that the work has already been done once, or several times in the past, while this would need to start from scratch). > I just have a > failure of imagination as to how the current setup, with all its options > (which are there for a reason, so need to be available) could be > supported in cmake or meson or anything else. Both systems are configurable in a very similar way. When you configure the build, you can pass as many options as the author of the build scripts came up with. You can always configure whether you want an external or a built-in library, you can always configure which binaries you want to get built (you could easily say that you only want luatex and xetex, plus whatever dependencies are, excluding hundreds of other targets), that you want X11 turned on or off, that you want to change the installation path, man pages here, binaries there, texmf there, ... > The bottom line for me is that if there is any impetus to switch, the > work will have to be done by someone other than me, and I will no longer > work on configuration. I just can't do it. --best, karl. Again, there is no need to switch (it *should* be just an additional alternative, at least for the first few yearl), and there's probably too much work to be done by one single person, no matter what. Again, my main concern is manpower. I was just curious whether there was in fact something that we could no achieve. I talked to Peter B. about CMake many years back. He was not opposing CMake configuration, he just wasn't too enthusiastic about the immediate cost / benefit ratio that writing such a system would bring. The only immediate benefit would be out-of-the-box support for Windows, and badly-written configuration would probably be worse than none at all :) A very well-written configuration on the other hand could perhaps in addition allow selecting a scheme and then build & install a full TeX Live scheme (binaries + copy packages + write configuration file). Mojca From karl at freefriends.org Tue Dec 25 00:25:00 2018 From: karl at freefriends.org (Karl Berry) Date: Mon, 24 Dec 2018 16:25:00 -0700 Subject: [tlbuild] Bug in kpse-icu-flags.m4: a long-standing OpenBSD build failure In-Reply-To: Message-ID: <201812242325.wBONP0RY027959@freefriends.org> Back on this mail from April 2017 and earlier (sorry): https://tug.org/pipermail/tlbuild/2017q2/003799.html To summarize, icu needs -lpthread on openbsd (but nothing else among our systems). I previously hacked in an ICU_LIBS_EXTRA variable back then to make it more convenient to add manually: https://tug.org/pipermail/tlbuild/2017q2/003812.html I've left in ICU_LIBS_EXTRA, but now I've also changed kpse-icu-flags.m4 to add the -lpthread automatically on openbsd. r49495. Although it would be better to link a test program to see if it is necessary, that would be lots more complicated, and I had no suitable test program at hand, and since in our case the reality is that openbsd is all that needs it (as far as I've heard?), I just hardwired it: pin Build/source/m4/kpse-icu-flags.m4] # checking for openbsd to add -lpthread for icu. case $build_os in openbsd*) eval AS_TR_CPP($1)_LIBS=\"$[]AS_TR_CPP($1)_LIBS -lpthread\" ;; esac which amounts to ICU_LIBS="$ICU_LIBS -lpthread"; except it seemed nicer to use the code that will work regardless of non-identifier characters in the library name, etc. I added some more debugging/logging messages to the m4 macros while I was at it. Searching for "tldbg" in the config.log file and configure scripts should show more traces of what's happening now. > ./Work/libs/icu/icu-build/config/icu-config \ > --prefix=/path/to/Work/libs/icu/icu-build \ > --ldflags-system I decided not to use icu-config because that would induce a dependency on libpthread.so on, so far as I can see, most or all (Unixish) platforms. This does not seem like a good idea. That is, looking at the built icu-config script on my CentOS7, where -lpthread is not needed, but it is still included in the output: LIBS="-lpthread -lm " (libm is not needed either on this system.) Maybe libpthread is ubiquitious among the systems we build binaries for, but ... maybe not ... As far as I know, the TL configure scripts only call pkg-config to configure a library when the system library is being used, not the library from TL. This certainly has its pros and cons, but I'm not inclined to make (the huge effort for) a wholesale switch without clear proof that it would be better. From the above, I'm guessing it would be worse, in terms of cases that have to be fixed. Hope I didn't mess up too badly. --thanks, karl. From preining at logic.at Tue Dec 25 02:46:30 2018 From: preining at logic.at (Norbert Preining) Date: Tue, 25 Dec 2018 10:46:30 +0900 Subject: [tlbuild] CMake In-Reply-To: <201812240008.wBO08UpP013093@freefriends.org> References: <201812240008.wBO08UpP013093@freefriends.org> Message-ID: <20181225014630.GC15596@burischnitzel.preining.info> On Sun, 23 Dec 2018, Karl Berry wrote: > The bottom line for me is that if there is any impetus to switch, the > work will have to be done by someone other than me, and I will no longer > work on configuration. I just can't do it. --best, karl. I think this is the core point. After Peter passed away most of the auto* stuff was done by Akira and Karl, and a bit by me (don't get angry if I forgot someone). We try to keep that going. Another build system needs a lot of work to develop, but above that it needs a certain dedication in the future, too. If the developer of an alternative build system just happens to loose interest in TeX for whatever reason (work, ...), who will care for the build system when the current core members have no experience with them - and probably no time to learn a new build system? Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13