On Sat, Jun 6, 2020 at 9:37 PM Rugxulo <rugx...@gmail.com> wrote: > On Tue, Jun 2, 2020 at 12:26 PM dmccunney <dennis.mccun...@gmail.com> wrote: > > > > > DJGPP make is mainly just a port of GNU make, is it not? > > > > Well, as part of a port of the entire Gnu/Linux toolchain, including > > GCC. Things like Scons are displacing make in some contexts, but make > > isn't going away. > > Make is a fairly useful util and a great idea, but it's also a > portability nightmare (isn't everything?). So it's hard to do anything > perfectly.
I have unfond memories of trying to build stuff with make, and discovering that the make I was using required *tabs* as separators in some areas, and would fail if spaces were used instead. (Editors I use tend to convert tabs to spaces.) I don't recall that particular requirement being *documented* anywhere, and since tabs are non-printing chars you have to jump through various hoops to explicitly display, looking at the makefile was no help, because you would see blank spaces and not realize they were generated by tabs instead of space chars. But make can be considered a language, and folks have done stuff in make that has nothing to do with building code. > Scons relies on Python, as do many things. POSIX Make seems somewhat > rare, so many projects just use GNU Make as the "portable" > alternative. CMake is popular, so is Meson (with NInja). But I'm not > directly familiar with most of them. There are other things as well. A partial list is here: http://texteditors.org/cgi-bin/wiki.pl?UnixMake > GNU only recommends these utilities: > > * > https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html And for good reason. Make may be portable. The code you build using it may not be, and architectural differences in the targets can bite. "Make relies on the following tools. Make sure versions of them are available on the system where you are building" is sound advice. So is advice like "Don't create symlinks in make, because they may not be available on the target of your build." > I know nothing about C++, but the latest '20 standard has modules, > which will probably speed up and simplify makefiles in the future > (hopefully). But I don't think major compilers are quite there yet > (but fairly close). > > * https://gcc.gnu.org/projects/cxx-status.html > > This is a big change and important to do correctly. So I don't blame > them for taking their time (not to mention that C++17 wasn't that long > ago and is generally fully supported). C++ has come a *long* way. Bjarne Sjoustroup created it while at AT&T. AT&T Unix's first C++ compiler was cfront. Cfront was a front end that parsed your c++ code and converted it to standard C, which could be compiled by cc to asm, assembled by as, and linked by ld to create an executable. I asked about that at a talk Sjoustroup gave at a Unix users group meeting. He said that people had been wishing for years for a truly portable assembly language, and they finally realized that's essentially what C was. C was designed to be portable, and efficient enough that you didn't have to write in assembler to get performance. Unix was originally written in the MACRO-11 assembly language provided by DEC in the system used to originally develop Unix. When C became mature enough, most of Unix was rewritten in it. If memory serves, perhaps 10% of the really low level code that talked to the hardware remained in assembler. AT&T implemented the original C++ as a parser converting to standard C because the hardware to support a native C++ compiler wasn't generally available. As more powerful hardware became available, true C++ compilers appeared. > (I did buy a DOS-based, pre-standard C++ book [1995] in 1998 with a > floppy containing Turbo C++ Lite. How quaint. I half read it but > didn't stick with it. There are better modern C++ books nowadays, > obviously.) More than I can count. > > > As for the AWK portion, I have tested my script for munging the > > > GW-BASIC source files with both GNU awk (gawk) and mawk. > > > > Were any changes required to your original script to get it to work as > > expected in gawk *and* mawk? > > There's always "dark corners" (as GAWK would call it), but mostly it > should work okay. Just be sure to rigorously test everything before > publishing (or at least mention exactly what version and OS you tested > on somewhere). Yes, I found some avoidable quirks by testing various > AWK interpreters on some simple scripts. Standards are good, but > actual testing of existing implementations is more crucial than > theoretical success. (Don't be a purist! Make it work with what you > have available.) The problem with standards is that everyone will have their own take on how to implement them, and I haven't seen a standard yet that didn't have grey areas, where people trying to implement them could come up with things that both adhered to the standard as written, but were incompatible in practice. IIRC, POSIX has a lot of areas like that. ______ Dennis _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
