Re: use of math.h / libmath discouraged?

[Eddy Petrișor]

joi, 26 iul. 2018, 19:42 Brian Vandenberg <address@hidden> a scris:

Wouldn't profiling information help? 

See details and link to code with 3.81 that does this at:

Yes, it would.  I was unaware of that issue.

It looks as though that feature never made it in [unfortunately].  If it were added, was present in a default build and there were a way to enable/disable it dynamically then what I'm proposing here wouldn't be much of an improvement (if any).

Yes, unfortunately, I did not get any feedback from the community except the initial one suggesting some unusable, IMO, output, while I was focusing on the usability of the feature without involving a long chain of external tools (raw output and LibreOffice Calc were enough in both my proposals).

There were since other minor portability issue which I was planning to address once the main design was agreed, but that did not happened, stated using another build tool which had profiling info and I lost interest in improving GNU make.

The enabling of the profiling feature was triggered by the passing of the command line parameter and was done at rule level and start and end of the make process. Finer granularity was not considered. 

When I say "enable it dynamically" I mean something along these lines:

$(profile_options ...formatting/level/etc goes here...)
# or
.PROFILE_OPTIONS := ...ditto...
$(enable profiling)
...some expressions not at recipe scope...
$(disable profiling)
$(profile some _expression_)
.RECIPEPREFIX := >
some_target:
> $(profile ${CC} ${FLAGS} ${<} -c -o address@hidden)

In lieu of that, what I'm proposing is worth adding in that it's not difficult to use, its footprint is small and can give insight that's otherwise difficult to glean.

I have no problems with being able to profile a build, I know the pain of managing a large build system and having no insight into the performance bottle necks.