1New features with AN-2021-09-18: 2 3This is the first localization step for the schily source consolidation. Many 4programs now (hopefully) call gettext() for all strings that need localization. 5 6- The next step will include dgettext() calls for the libraries and the 7 missing programs 8 9- The following step will include the extracted strings 10 11- The last step will include German translations and install support 12 for the resulting binary message object files. 13 14----------> Please test and report compilation problems! <--------- 15 16***** NOTE: As mentioned since 2004, frontends to the tools should ***** 17***** call all programs in the "C" locale ***** 18***** by e.g. calling: LC_ALL=C cdrecord .... ***** 19***** unless these frontends support localized strings ***** 20***** used by the cdrtools with NLS support. ***** 21 22 *** WARNING *** 23 *** Need new smake *** 24 25 *** Due to the fact that schily-tools 2014-04-03 introduced to use new macro 26 *** expansions and a related bug fix in smake, you need a newer smake 27 *** to compile this source. If your smake is too old and aborts, ensure to 28 *** use the recent smake by calling: 29 30 cd ./psmake 31 ./MAKE-all 32 cd .. 33 psmake/smake 34 35 .... become "root" and then call: 36 37 psmake/smake install 38 39 The new smake version mentioned above is smake-1.2.4 40 The recent smake version is smake-1.5 41 42 *** Due to the fact that schily-tools 2018-01-26 introduced 43 *** optimizations for the Schily version of SunPro Make, you 44 *** need at least the dmake version from 2018/01/11 with support 45 *** for the "export" directive to compile with this makefile system. 46 47For the beginning of the list of new features of the software in this tarball, 48please scroll down to "NEW FEATURES" 49 50 WARNING: the new version of the isoinfo program makes use of the 51 *at() series of functions that have been introduced by Sun 52 in August 2001 and added to POSIX.1-2008. For older platforms, 53 libschily now includes emulations for these functions but 54 these emulations have not yet been tested thoroughly. 55 Please report problems! 56 57 BUG WARNING: Please never report bugs only to Linux distributions as 58 they usually do not forward these bug reports upstream and 59 the Linux distributions typically do not let skilled people 60 check the bugs. We did not hear about a FIFO problem in star 61 for a long time. Then a problem on Linux occurred once 62 every 6000-10000 tries but it did not happen on Solaris after 63 even 10 million tries, so it was not known besides Linux and 64 not reported to the project. 65 66 BUG WARNING: *** GNU make *** starts too early with parallel 67 execution (when reading Makefiles and evaluating rules for 68 "include" statements already). Since GNU make does not 69 support a concept for a correct ordering of such actions, 70 you need to be prepared to see GNU make fail in parallel 71 mode. If you try to compile a maiden unpacked schilytools 72 tarball in parallel mode using GNU make, this will definitely 73 fail as a result of the GNU make timestamp caching bug. See 74 below for more information. 75 76 If you are interested in reliable parallel execution, 77 it is recommended to use the included "dmake" program with 78 a command line like: 79 80 dmake -j10 -r -f SMakefile 81 82 from the top level directory. Note that if you are on Linux, 83 you need the dmake version from schilytools 2021-06-07 or 84 newer, since that version introduced a solution for a kernel 85 caused performance problem with filesystems on Linux. Older 86 dmake versions will not be faster in parallel mode on Linux. 87 88 The "dmake" program included in the schilytools tarball is the 89 current version of the "new" SunOS make program that has been 90 introduced in January 1986 by Sun Microsystems. It also 91 introduced new features (like the "include" directive) that 92 3 years later have been copied by gmake in a partially buggy 93 way. As gmake does not fix showstopper bugs, it cannot be 94 supported. Current showstoppers are: 1) gmake executes 95 "include" related rules in the inverse order, causing rules 96 to fail if they depend on files created by an "earlier" action 97 2) gmake caches an outdated state of the directory and aborts 98 with a wrong complain about allegedly missing files that in 99 fact exist already, because they just have been remade. 100 101NEW FEATURES: 102 103- smake: Fixed a typo in a comment in readfile.c 104 105- smake: The man page now mentions that the commands called for 106 .INCLUDE_FAILED: should include $^ as argument to the rule command to 107 be able to know what filename is missing and to be pocessed. 108 109- smake: Fix a bug in the man page for .INCLUDE_FAILED:. It now 110 correctly mentions that .INCLUDE_FAILED: only applies to the "include" 111 directive but not to the "-include" directive as well (as claimed 112 before). 113 114- SunPro Make: The dynamic macro $^ is now documented in the man page. 115 It was always supported by SunPro Make, but for unknown reasons 116 undocumented in the official man page from Sun Microsystems. 117 118- SunPro Make: The .INCLUDE_FAILED: special target is now supported 119 the same was as in smake. 120 121 History: smake introduced .INCLUDE_FAILED: 23 years ago (in July 122 1998) in order to be able to support completely unknown platforms with 123 the schily makefile system. This works fine, since a bootstrap smake 124 is compiled first in schilytools and this is done via a shell script. 125 126 That specific use case in smake (with a completely unknown platform, 127 based on an unknown operating system or an unknown CPU) will not work 128 with SunPro Make the same way, since SunPro Make needs smake as a 129 bootstrap make program for compilation. In other words, SunPro Make 130 is compiled on unknown platforms, using a bootstrap smake that was 131 compiled with a shell script and before SunPro Make is compiled on a 132 completely unknown platform, smake did already run the automake 133 scripts triggered from the .INCLUDE_FAILED: target while smake was 134 running. 135 136 Adding support for .INCLUDE_FAILED: to SunPro Make however still 137 makes sense, as support for .INCLUDE_FAILED: in SunPro Make allows to 138 automatically add initial basic support for new compilers to a 139 development tree using the schily makefile system or similar build 140 systems, while being on a platform with pre-existig SunPro Make 141 binaries. This may even be more probable than the case with a 142 completly unknown OS. 143 144- SunPro Make: .INCLUDE_FAILED: special target 2nd group of changes: 145 146 .INCLUDE_FAILED: is no longer supported when make is in SVr4 mode 147 or when it is in compatibility mode to old SunPro Make versions. 148 149 .INCLUDE_FAILED: no longer permits dependencies to appear after the 150 colon. These dependencies have been previously ignored. 151 152 .INCLUDE_FAILED: is now better printed with make -p, since 153 .INCLUDE_FAILED: now appears in the first block of output that lists 154 .PHONY:, .PRECIOUS:, .SUFFIXES: as well. 155 156- SunPro Make: A new section "Automake Features" has been added. 157 158- SunPro Make: A new version date has been defined. 159 160 161SCCS THOUGHTS: 162 163- SCCS: The current idea for converting a historic SCCS project into 164 a project oriented SCCS history bundle is the following: 165 166 - Create a user map file for "sccslog" by calling: 167 168 mkdir $HOME/.sccs 169 $EDITOR $HOME/.sccs/usermap 170 171 Enter the UNIX login names followed by a TAB, followed 172 by an E-mail notation. Use one line per user, e.g. 173 174 joerg J. Schilling <joerg@mail.com> 175 176 - Create a copy of the whole project to work on for this test. 177 Do not do this conversion on the original project until 178 sccs-6.0 is ready. 179 180 - chdir to the project home directory of the just created copy. 181 182 - Call "sccs init -i ." to make the project using an in-tree 183 project oriented repository. 184 185 - Call: 186 187 find * -path '*SCCS/s.*' | /opt/schily/ccs/bin/sccscvt -NSCCS/s. -k -ooo -V6 - 188 189 for the CSRG BSD project use: 190 191 find * -path '*SCCS/s.*' | TZ=US/Pacific /opt/schily/ccs/bin/sccscvt -NSCCS/s. -k -ooo -V6 - 192 193 to convert all history files into SCCSv6 history files. The 194 TZ=US/Pacific is important for the UCB conversion since SCCSv6 195 uses timezones but SCCSv4 does not and we need to have the 196 correct timezone entries in the SCCSv6 history files. 197 198 For the complete "schilytools" project with 4200 SCCS history 199 files in 55 Mbytes, this takes 12 seconds for the SCCS history 200 from 1984 .. 2020, but note that most of the edits from the 201 1980s are lost, so there are few entries from the time 202 before 1989. 203 204 An alternate example: the SCCS history from the BSD-4.4 project 205 from December 1979 up to June 1995 is in 12600 SCCS history 206 files that take up 125 MB. 207 The conversion time to the SCCSv6 history file format is 208 18 seconds. 209 210 - Call: 211 212 find * -path '*SCCS/s.*' | /opt/schily/ccs/bin/sccslog -changeset - 213 214 to populate the changeset file from the existing deltas. 215 216 For the complete "schilytools" project with 19600 commits, 217 this takes 8 minutes. The resulting file .sccs/SCCS/s.changeset 218 has a size of approx. 7 MBytes. 219 220 An alternate example: the SCCS history from the BSD-4.4 project 221 from December 1979 up to June 1995 has approx. 47000 commits. 222 The conversion time is approx. 40 minutes. 223 The size of the resulting changeset file is approx. 14 MBytes. 224 225 - convert the in-tree repository into an off-tree repository. 226 This final step is not yet needed and there is currently no 227 code to do that automatically. 228 229 - If you like to check the resulting changeset file, there is 230 currently only one way to look at it, by calling: 231 232 sccs -O get -p -A -m .sccs/SCCS/s.changeset | more 233 234 This prints an annotated version of the changeset file. 235 The next task is to develop an enhancement to "sccs log" 236 that prints the changeset in a way similar to what "hg log -v" 237 prints. 238 239 - NOTE: Normal filesystems on Linux are slow, it is advised to 240 make the conversions on tmpfs for performance reasons in case 241 you are using Linux. 242 243 Please however keep in mind that this is still experimental and there is 244 absolutely no grant that a changelog created with current experimental 245 software will work correctly with the final SCCS version. The procedure 246 is just an example to check how it may look like. 247 248 The final conversion method will be more automated... most likely 249 by a command similar to "sccs import ..." 250 251 IMPORTANT: This is not yet the time to finally convert a project into 252 the project mode, because the project would be stuck in the current 253 state. What we need to continue work in that repository state in the 254 project mode is at least a working "sccs commit". Be prepared to remove 255 the changeset history file once "sccs commit" works and to re-create 256 the changeset file for that time. 257 258 259 260- SCCS TODO: 261 262 - Activate "fsdiff" as a "bdiff" replacement in delta(1) 263 to speed up delta(1) and to reduce the size of the SCCS 264 history files. 265 266 - Implement something that outputs similar information from 267 the changeset file as printed with "hg log -v". 268 269 This would be the next key feature. 270 271 - verify whether sccs.c uses -NSCCS in the back end programs 272 correctly, instead of converting g-file names from the command 273 line into s.file names in the frontend in order to forward 274 s.file names to the backend programs. This is needed for an 275 off-tree repository. 276 277 The related unit tests are already passed. 278 279 - Add code to to sccs(1) to send a list of files to admin(1) and 280 delta(1) with new or modified files in order to have all 281 important code for a "sccs commit" in a single program that 282 does not need to deal with ARG_MAX limitations. 283 284 - Add code to admin(1), delta(1), sccs-log(1) and get(1) to 285 maintain/understand the changeset file. 286 287 This is mainly writing out the sccschangeset(4) entries to an 288 intermediate store if a single file has been treated 289 successfully. For sccs-log(1), see below. 290 291 - Finish the work to allow normal line based diffs in SCCS even 292 for binary files. This are files that include nul bytes and 293 this needs to completely avoid fputs() and this needs an 294 initialized member p_line_length in struct packet even for 295 all content that does not result from a previous getline() call. 296 297 - sccs -R tell (and probably other subcommands?) does not yet 298 work in NewMode 299 300 - Add code to libcomobj to understand the changeset file. 301 This is needed in order to e.g. know the file names and file 302 specific SIDs/state that corresponds to a project global SID. 303 304 - Find/verify a complete transactional model that allows to repair 305 complex changes to the set of files for a project that have 306 been aborted in the middle. The current idea is to create the 307 file $PROJECTHOME/.sccs/changeset with the deltas to the 308 changeset during a complex update operation. 309 310 - Find a decision on how to deal with the admin flags that are 311 currently implemented as global flags and thus do not depend on 312 the SID (version) if the history file. 313 314 - Aborting a transaction via ^C currently requires a manual 315 removal of the global lock file. Find a way to avoid this in 316 case that a commit has been aborted while being prompted for 317 a commit message (which is before any real action happened). 318 319 - Implement a fully automated method to convert a SCCSv4 based 320 history with unrelated history files into a new SCCSv6 based 321 project mode history with a populated changeset history file. 322 323 This will most likely be done as a variant of the to be defined 324 new command "sccs sccsimport" that imports a whole existing old 325 SCCS project. 326 327 - Implement this "sccs sccsimport" based conversion in a way where 328 sccs(1) holds the global changeset lock for the whole time 329 of the conversion. 330 331 332 333 334- Bourne Shell Missing features for POSIX compliance: 335 336 - Support for $'...' quoting (this is not needed for the current 337 version of POSIX but for the next POSIX 338 version that will be named SUSv8). 339 The development of SUSv8 will start in 340 late 2016. 341 342 We are now expecting the Bourne Shell to be fully POSIX compliant. 343 344- Bourne Shell further TODO list: 345 346 - Finish loadable builtin support. 347 348 - POSIX does not allow us to implement ". -h", so we will 349 add a "source" builtin to be able to implement "source -h" 350 351- The following builtins (that are available in bsh) are still missing in 352 the Bourne Shell: 353 354 err echo with output going to stderr 355 glob echo with '\0' instead of ' ' between args 356 env a builtin version of /usr/bin/env 357 358 The following bsh intrinsics are still missing in the Bourne Shell: 359 360 - the restricted bsh has restriction features that 361 are missing in the Bourne shell. 362 363 - source -h read file into history but do not execute 364 365 and probably more features not yet identified to be bsh unique. 366 367 368 369Author: 370 371Joerg Schilling 372D-13353 Berlin 373Germany 374 375Email: joerg@schily.net 376 377Please mail bugs and suggestions to me. 378