Tuesday, January 14, 2020

Digest for comp.lang.c++@googlegroups.com - 5 updates in 2 topics

Nikki Locke <nikki@trumphurst.com>: Jan 14 11:23PM

Available C++ Libraries FAQ
 
URL: http://www.trumphurst.com/cpplibs/
 
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
 
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
 
Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 14 10:47PM +0200

On 14.01.2020 15:38, Frederick Gotham wrote:
 
> .PHONY: uninstall
> uninstall:
> $(RM) $(DESTDIR)/$(PROGRAM)
 
I agree with other responders. The above looks more like assembler or
PostScript code, i.e. not really something meant for humans to write.
And the result looks pretty non-portable and limited to a single type of
projects.
 
While I have done my share of makefile programming in the past I'm ready
to admit I never got it quite right; by looking at makefiles generated
by CMake I can now understand why.
 
So what's wrong with using CMake instead?
Siri Cruise <chine.bleu@yahoo.com>: Jan 14 01:38PM -0800

In article
<878b2dc4-fbfe-4f1d-b7e7-4f71fb9a8610@googlegroups.com>,
 
> What would be the best way to implement "make install" as portably and
> generically as possible? Here's what I've got so far:
 
Don't use make. Use a bourne shar. Deal with parameters,
interrogate the environment, etc and write out the payload and
the makefile where convenient. Then do the make.
 
Keep the script readable and as short as possible. Keep the
makefile readable.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
Siri Cruise <chine.bleu@yahoo.com>: Jan 14 01:39PM -0800

In article <qvl9c9$148$1@dont-email.me>,
 
> So what's wrong with using CMake instead?
 
What's not?
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 14 10:07PM

On Tue, 2020-01-14, Paavo Helde wrote:
>> C/C++ program from all the source files in the current
>> directory. I've been using this Makefile for the past few months on
>> loads of different programs (big and small) and it works well.
 
...
 
>> DEPENDENCIES += $(OBJECTS:.o=.d)
 
>> .PHONY: all
>> all: $(PROGRAM) $(DEPENDENCIES)
...
 
> PostScript code, i.e. not really something meant for humans to write.
> And the result looks pretty non-portable and limited to a single type of
> projects.
 
I believe that was his goal: a single Makefile for all matching
projects, not meant to be easily read and understood.
 
Like I argued the first time around, a hand-written Makefile,
written /for a certain project/, can be written clearly and elegantly
(modulo a dozen lines of boilerplate for the dependency generation).
 
IMO, this one of mine is an example: <git://snipabacken.se/groblad>.
 
But the OP wanted (as I understood it last time) a Makefile he could
copy into any directory containing source code, so he could ignore
whatever build system was already in place.
 
> While I have done my share of makefile programming in the past I'm ready
> to admit I never got it quite right; by looking at makefiles generated
> by CMake I can now understand why.
 
It's autogenerated makefiles, designed to use recursive make strategy;
they are bound to be atypical.
 
> So what's wrong with using CMake instead?
 
Personally I've never been able to understand CMake. Trivial tasks are
easy; other tasks end up, IME, an exercise in cargo-culting and
trial-and-error.
 
For the OP's use case, CMake could be a better fit.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)