Path: csiph.com!news.swapon.de!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail From: antispam@fricas.org (Waldek Hebisch) Newsgroups: comp.lang.c,comp.lang.python Subject: Re: Python recompile Date: Mon, 10 Mar 2025 14:39:27 -0000 (UTC) Organization: To protect and to server Message-ID: References: <20250304092827.708@kylheku.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Mon, 10 Mar 2025 14:39:27 -0000 (UTC) Injection-Info: paganini.bofh.team; logging-data="3498353"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A"; User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64)) X-Notice: Filtered by postfilter v. 0.9.3 Xref: csiph.com comp.lang.c:390946 comp.lang.python:197371 In comp.lang.c Lawrence D'Oliveiro wrote: > On Thu, 6 Mar 2025 19:21:45 -0000 (UTC), Waldek Hebisch wrote: > >> Per platform Makefile-s do not scale when one wants to support multiple >> system and multiple configurations (there is exponential growth of >> possible combinations). And even of single configuration for supposedly >> single system like Linux there are troubles. >> In one project there was someting like 20 Makefile.linux_x files where x >> represented one Linux flavour. Yet regularly somebody would come and >> say: "build fails on my Linux x.y.z". If enough information was >> provided new Makefile was added, or possibly some similar Makefile was >> modified to cover more cases. > > Can you offer more details on the project in question? I ask because > there are things that can be done in GNU Makefiles to deal more > dynamically with environmental differences in some simpler cases, > without resorting to a full-on meta-build system like Autotools or > CMake, and perhaps the maintainers of this project aren’t aware of > that. I guess that one could do configure-like processing inside a Makefile generating next stage Makefile. Autoconf offers ready-to-use functionalty, like a bunch of sanity checks or check for X libraries. There are several subdirectories each containing its own Makefile, propagating info via substitution + fixed makefile fragments looks esier than Makfile includes + conditionals that would be required in make-only solution. If you look at scale, there is something like 2000 source file in various languages (including about 50000 wc lines of C). About 450000 wc lines total, including tests and documentation (but documentation requires rather involved build process). About 140 MB generated files. Some currently suported features: - using onf of 5 different non-C compilers, each having diferent extentions for compiled files and needing different way of creating executable - matching linking options (shared versus static) and needed libraries to used compiler - blacklisting buggy compiler versions - optionally including/excluding part of functionality - optinally using machine independent pre-build files (saves compile time for users building from source) All this requires some code. It is possible that the work could be done with less code. However, history suggest conservative approach. Shortening the whole story, this is largish formerly propritary program that was released as open source. First 6 years of open source developement was mainly spend on build issues. Nontrivial part on build system, parts on improving portablity of code, changing tools, etc. Current autoconf based build system probably represent about 1 man year of developement effort. During last 15 years build system worked requiring small maintanence effort. History indicates that changing build system at least requires some non-trivial effort. And there is ample opportunity for troubles. So simply, why spend effort on replacing something that works? Let me mention due to disagreemnts (including build system, but not only) project forked. There is or maybe was (in last few years it made no release) fork which does not use autoconf and depends on multiple configuration files. It offered less flexibility and still regularly had build failures due to changing Linux configurations. -- Waldek Hebisch