Friday, October 4, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 04 07:37AM -0700

On Friday, October 4, 2019 at 2:54:58 PM UTC+1, Scott Lurndal wrote:
> in over 40 years of programming that didn't explicitly specify all the objects
> (and the rules to build them if the default rules were insufficient) necessary to build
> the target (whether an executable, a library or both).
 
 
 
To have a file in the directory listing for a project is quite explicit. In fact, I could argue that you can't get much more explicit than that.
scott@slp53.sl.home (Scott Lurndal): Oct 04 02:52PM

>> (and the rules to build them if the default rules were insufficient) necessary to build
>> the target (whether an executable, a library or both).
 
>To have a file in the directory listing for a project is quite explicit. In fact, I could argue that you can't get much more explicit than that.
 
$ ls
ASMBLR Makefile.rules docs main.cpp notes tests
Makefile Makefile.version include main.d pkg utilities
Makefile.ddk common io main.o processor vsim
Makefile.defs data lib mp tapes
 
How does your approach deal with subdirectories?
 
$ ls io/dlps
5n_dlp.cpp file_tape_unit.cpp qwik_dlp.h
5n_dlp.d file_tape_unit.d qwik_dlp.o
5n_dlp.h file_tape_unit.h scsi_disk_dlp.cpp
5n_dlp.o file_tape_unit.o scsi_disk_dlp.d
Makefile fips_tape_dlp.cpp scsi_disk_dlp.h
Makefile.ddk fips_tape_dlp.d scsi_disk_dlp.o
buffered_printer_dlp.cpp fips_tape_dlp.h scsi_tape_dlp.cpp
buffered_printer_dlp.d fips_tape_dlp.o scsi_tape_dlp.d
buffered_printer_dlp.h gcr_dlp.cpp scsi_tape_dlp.h
buffered_printer_dlp.o gcr_dlp.d scsi_tape_dlp.o
card_punch_dlp.cpp gcr_dlp.h ssp.cpp
card_punch_dlp.d gcr_dlp.o ssp.d
card_punch_dlp.h ht_dcp_dlp.cpp ssp.h
card_punch_dlp.o ht_dcp_dlp.d ssp.o
card_reader_dlp.cpp ht_dcp_dlp.h ssp_dlp.cpp
card_reader_dlp.d ht_dcp_dlp.o ssp_dlp.d
card_reader_dlp.h ht_dpdc_dlp.cpp ssp_dlp.h
card_reader_dlp.o ht_dpdc_dlp.d ssp_dlp.o
card_unit.cpp ht_dpdc_dlp.h st_tape_unit.cpp
card_unit.d ht_dpdc_dlp.o st_tape_unit.d
card_unit.h htseq_dlp.cpp st_tape_unit.h
card_unit.o htseq_dlp.d st_tape_unit.o
disk_unit.cpp htseq_dlp.h tape_unit.cpp
disk_unit.d htseq_dlp.o tape_unit.d
disk_unit.h iocb.cpp tape_unit.h
disk_unit.o iocb.d tape_unit.o
dlp.cpp iocb.o telcom_dlp.cpp
dlp.d isc_dlp.cpp telcom_dlp.d
dlp.o isc_dlp.d telcom_dlp.h
file_card_unit.cpp isc_dlp.h telcom_dlp.o
file_card_unit.d isc_dlp.o train_printer_dlp.cpp
file_card_unit.h odt_dlp.cpp train_printer_dlp.d
file_card_unit.o odt_dlp.d train_printer_dlp.h
file_disk_unit.cpp odt_dlp.h train_printer_dlp.o
file_disk_unit.d odt_dlp.o uniline_dlp.cpp
file_disk_unit.h printer_unit.cpp uniline_dlp.d
file_disk_unit.o printer_unit.h uniline_dlp.h
file_printer_unit.cpp qwik_dlp.cpp uniline_dlp.o
file_printer_unit.h qwik_dlp.d
 
A fragment of io/dlps/Makefile:
 
libdlp_fips_tape.so: fips_tape_dlp.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_htseq.so: htseq_dlp.o disk_unit.o file_disk_unit.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_uniline.so: uniline_dlp.o dlp.o $(LIBCOMMON)
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+
 
libdlp_odt.so: odt_dlp.o dlp.o $(LIBCOMMON)
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_scsi_disk.so: scsi_disk_dlp.o disk_unit.o file_disk_unit.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_scsi_tape.so: scsi_tape_dlp.o tape_unit.o file_tape_unit.o dlp.o st_tape_unit.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+
 
libdlp_gcr.so: gcr_dlp.o dlp.o tape_unit.o file_tape_unit.o st_tape_unit.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_5n.so: 5n_dlp.o disk_unit.o file_disk_unit.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_reader.so: card_reader_dlp.o card_unit.o file_card_unit.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
 
libdlp_tpr.so: train_printer_dlp.o dlp.o
@echo " BUILD $(LIB)/$@"
$(HUSHCOMPILE)$(CC) -o $(LIB)/$@ $(SOLDFLAGS) $+ -lc
David Brown <david.brown@hesbynett.no>: Oct 04 05:19PM +0200

On 04/10/2019 16:52, Scott Lurndal wrote:
> buffered_printer_dlp.o gcr_dlp.d scsi_tape_dlp.o
> card_punch_dlp.cpp gcr_dlp.h ssp.cpp
> card_punch_dlp.d gcr_dlp.o ssp.d
 
I don't mix object files with source code - that quickly gets really
messy, and is terrible if you have multiple builds.
 
And haven't you read "Recursive make considered harmful" ? A Makefile
in a subdirectory?
 
My typical setup would be to have "Makefile" and perhaps a few other
files in the project root directory - things like utility scripts used
as part of the build project. (If there are many of them, they go in
their own directory.)
 
Source is all under a "src" directory - with subdirectories for
different parts of the code, such as third-party code, test code, etc.
This will obviously depend on the size of the project.
 
Auxiliary files such as linker scripts go in their own directory, which
is sometimes under "src" and sometimes under the project root (I am not
always consistent). Configuration files for debuggers, test scripts,
implementation documentation, etc., have their own directories as needed.
 
Then there is a "bin" directory for the generated binaries, and a
"build" directory for the built files. Directly under "build" will be
directories named for different build variations - the same source might
be used to build variants for different embedded hardware versions, or
PC test versions, or whatever. Under these, I have directories "dep",
"lst" and "obj" which have sub-directories mirroring the src structure
(this is all created automatically by the Makefile), containing the
dependency files, listing files and object files generated while building.
 
Everything is handled by a single "make". The Makefile is not
completely automatic or portable - it holds information about the
variants to be built, particular flags, directories, etc. But it avoids
the detailed work of tracking each file.
scott@slp53.sl.home (Scott Lurndal): Oct 04 04:13PM

>> card_punch_dlp.d gcr_dlp.o ssp.d
 
>I don't mix object files with source code - that quickly gets really
>messy, and is terrible if you have multiple builds.
 
I don't generally; that's an old non-proprietary project; but for that project, it
never caused issues. Generally we have 'release' and 'debug' directories
in each subdirectory to hold the '.o' and '.d' files (compiled for release
and debug respectively). bin and lib directories at the top level. A
top level Makefile.rules and Makefile.defs which is included from every
subdirectory Makefile which makes the subdirectory Makefiles very small,
easy to maintain and suitable for parallel builds.
 
 
 
>And haven't you read "Recursive make considered harmful" ? A Makefile
>in a subdirectory?
 
I've read it, and I completely disagree with almost everything in that document.
 
There's nothing inherently wrong with recursive make; particularly given
that his primary complaint was slow builds in 1997. Twenty two years
of Moores Law has pretty much killed that argument.
 
There is no problem supporting parallel makes in a recursive make enviroment
either.
Ian Collins <ian-news@hotmail.com>: Oct 05 08:04AM +1300

On 05/10/2019 02:54, Scott Lurndal wrote:
> in over 40 years of programming that didn't explicitly specify all the objects
> (and the rules to build them if the default rules were insufficient) necessary to build
> the target (whether an executable, a library or both).
 
I take it from that you have never use premake? It follows the "if a
".cpp" or ".c" file exists in the folder, it's there to be compiled"
philosophy and generates one fat "Makefile" (in our case, a ninja build
file or visual studio solution).
 
--
Ian.
scott@slp53.sl.home (Scott Lurndal): Oct 04 07:51PM

>> (and the rules to build them if the default rules were insufficient) necessary to build
>> the target (whether an executable, a library or both).
 
>I take it from that you have never use premake?
 
No. I did use ant back around the turn of the millenium;
I did't like it.
 
javac has the property, if I recall correctly, that it will
compile all .java files in a directory with a single invocation; That may work for java,
but not for most of the C or C++ projects that I've worked on or
with.
scott@slp53.sl.home (Scott Lurndal): Oct 04 01:58PM

>> You really don't want people to fail to compile the code just because
>> you have written "auto main(void) -> int" - they will not judge you kindly.
 
>But there's also the third reason
 
What's that? Baiting the cognoscenti?
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 04 07:30AM -0700

On Friday, October 4, 2019 at 2:59:01 PM UTC+1, Scott Lurndal wrote:
 
> >But there's also the third reason
 
> What's that? Baiting the cognoscenti?
 
You have to admit it looks pretty damn cool, especially if you're been writing "int main" for a decade or two or three.
scott@slp53.sl.home (Scott Lurndal): Oct 04 02:43PM


>> >But there's also the third reason
 
>> What's that? Baiting the cognoscenti?
 
>You have to admit it looks pretty damn cool, especially if you're been writing "int main" for a decade or two or three.
 
Frankly if I was interested in verbosity, I'd program in COBOL :-)
 
int main(int argc, const char **argv) is just fine.
Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 04 07:50AM -0700

On Friday, October 4, 2019 at 3:43:47 PM UTC+1, Scott Lurndal wrote:
 
> int main(int argc, const char **argv) is just fine.
 
 
That's as bad as using a C-style cast instead of static_cast
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 04 06:56PM +0200

On 04.10.2019 15:30, David Brown wrote:
> #if __cplusplus < 201103
> #error This code requires C++11 or newer
>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)