joi, 26 iul. 2018, 19:42 Brian Vandenberg <> a

> 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)
>> some_target:
>> > $(profile ${CC} ${FLAGS} ${<} -c -o ${@})
> 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.
Bug-make mailing list

Reply via email to