|
From: (Joerg S. <sc...@sc...> - 2021-01-09 13:30:49
|
Noel Butler <noe...@au...> wrote: > On 10/03/2020 22:52, Joerg Schilling wrote: > > > cd psmake > > ./MAKE-all > > cd .. > > psmake/smake > > and install, it will install everything? Not just cdrecord. Well, first a question: is there a reason for answering after such a long time? This seems to be from 10 months ago... Did something change since then? Since there are no outstanding bugs in schilytools, this does not seem to be a reminder for outstanding bugs. Installing "all" into a prototype area is the typical preparation for creating binary packages. The tree below "pkgdefs/OCSW" contains the meta data for UNIX packages. If you are maintaining a disrtro that uses a private binary packaging format, you would need to manually convert the existing meta data into your private format. If you like to directly install, you are free to chdir into a selection of subdirectories and to call "make install" from these subdirectories, implementing your private selection. > I'm just trying to understand why slackware about-to-be-released new > latest distro is still on 3.0.1 Since I am not slackware, I cannot answer this question. Please ask slackware people. > it seems the quiet change that nobody I know has heard of the move to > schilytools and a lot of stuffing around just to build cdrecord (because > of your 2 decade old spat with make and linux in general) and trying to > sway people t use your version of a make... its no wonder people give > up, and the users always lose. Well, the reason for introducing schilytools in December 2007 was mainly to reduce the effort for maintaining so much software in a way that permits more frequent updates. Since then, udates have become available in an average frequency of once every three weeks, even if a single sub-project did not change enough to justify a new release. As a side effect, this also makes it easier to deal with platforms that do not include a standard UNIX make program but rather ship an own version of make that is not fully POSIX compliant or that does not support the needed enhancements in a way that is needed for a portable build environment. The trick here is that schilytools include a shell script controlled bootstrap for the oldest (nearly 40 years old) OSS make implementation that is compliant enough to support the features needed to grant portability to all supported target platforms. Smake does not yet support parallel builds, but it is the most portable make implementation and there are still other fully supported make implementations... BTW: Since 4 years, schilytools also includes a portable version of SunPro Make that is not yet as portable as smake, but still at least as portable as e.g. gmake. SunPro Make is a 100% rewrite of the classical UNIX make program that was first published by Sun Microsystems in January 1986 with SunOS-3.2. It offered a lot of new features first seen on UNIX, e.g.: - The include directive - Pattern macro substitutions - Pattern based implicit rules - target specific maco definitions All modern make implementations recreated ideas from SunPro Make, including "gmake" that has been introduced in 1989 (which is three years after it's blueprint SunPro Make). The unfortunate problem with gmake is that it introduced plenty of bugs in corner cases while reimplementing SunPro Make features and that bug reports do not result in fixes. This may be caused by it's current maintainer that started in 1996 and does not know the background of decisions. Just as a side note: the currently most annoying problem in gmake is that it starts parallelized work too early and does not offer a method to control the execution order of critical sections in the process of handling dependencies with the include directive processing. This causes gmake to mostly fail in parallel mode with the Schily Makefile system. So if you do not like smake for some reasons, you may like to install SunPro Make and get a POSIX certified UNIX make implementation that is fully supported by the Schily Makefile system and that supports parallel builds. Jörg -- EMail:jo...@sc... Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ |