Re: Compacting link-rules

Will do. Eddy vin., 19 oct. 2018, 16:52 Paul Smith a scris: > On Fri, 2018-10-19 at 09:26 +0300, Eddy Petrișor wrote: > > I have a similar issue, but in my case I used explicit pattern rules, > > vpath and added compiler generated .d files to make sure the object > >

Re: Compacting link-rules

joi, 18 oct. 2018, 18:56 Paul Smith a scris: > On Thu, 2018-10-18 at 17:40 +0200, Gisle Vanem wrote: > >bin/%.exe: $($(@F)_OBJ) $(LIBS) > >$(call link_EXE, $@, $^) > > This cannot work because automatic variables like $@, etc. are only > valid _inside a recipe_. They are not set

Re: use of math.h / libmath discouraged?

joi, 26 iul. 2018, 19:42 Brian Vandenberg 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,

Re: use of math.h / libmath discouraged?

Eddy mie., 25 iul. 2018, 23:26 Brian Vandenberg a scris: > However, I'm not sure that this function is sufficiently generic to be >> > added as a built-in function. Can you provide use-cases for it? >> > > I suppose that depends on the definition of "sufficiently generic". The > two

Re: Converting make rules into other file formats

Pe 15 oct. 2017 12:57 PM, "SF Markus Elfring" a scris: > Are the chances better to extend the tool “remake” then? … > Probably. Can it be that our software development resources are also too limited for mentioned tasks? I don't know. > My intention was to

Re: Converting make rules into other file formats

ur build and execution framework to be able to easily identify bottlenecks. The dependency graphing feature was also present in the branches I was planning to upstream since it allowed me to check if the dependencies in our build system were incorrect from a logical PoV (started with a sequential

Re: Converting make rules into other file formats

simple formatting of info is too much for make to do. Here is the bug report: https://savannah.gnu.org/bugs/?40639 Eddy Petrișor Pe 14 oct. 2017 10:47 PM, <th...@vmware.com> a scris: > SF Markus Elfring writes: > > > A Makefile is basically a human-readable text file

Re: [bug #40639] GNU Make with profiling information

Pe 11.01.2014 20:58, Paul Smith psm...@gnu.org a scris: Sorry, I've been mostly away from my systems recently. On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: Thanks for clarifying this. Could you please confirm if the general direction of the the is OK in the latest patch I sent

Re: [bug #40639] GNU Make with profiling information

2014/1/12 Paul Smith psm...@gnu.org: On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote: Could you please confirm if the general direction of the the is OK in the latest patch I sent? Conceptually it seems OK. I'm still not jazzed about having any more than one output format, and I'd

Re: [bug #40639] GNU Make with profiling information

code to review). In any case, fixed/floating point seconds since 1970 is the nicest format to process from scripts in my experience. That is what is printed now, where applicable. -- Eddy Petrișor ___ Bug-make mailing list Bug-make@gnu.org https

Re: [bug #40639] GNU Make with profiling information

Paul, I would really appreciate feedback on this. If the problem is the licensing, don't worry about my rights, I will gladly give them to the FSF. Pe 18.12.2013 13:28, Eddy Petrișor eddy.petri...@gmail.com a scris: Pe 15.12.2013 18:07, Paul Smith psm...@gnu.org a scris: On Sun, 2013-12

Re: [bug #40639] GNU Make with profiling information

Pe 15.12.2013 18:07, Paul Smith psm...@gnu.org a scris: On Sun, 2013-12-15 at 13:38 +, Tim Murphy wrote: I suppose I'm skirting around saying that I think gnu make needs an output format in the same way that valgrind has --xml=yes. I'm not an XML fan really - JSON might be an

Re: [bug #40639] GNU Make with profiling information

in the output without informing the parser at all. Currently the prefix and the field separators are customisable. Maybe an example could help. Again, this is only an opinion - it carries no weight. Regards, Tim On 29 November 2013 02:43, Eddy Petrișor eddy.petri...@gmail.com wrote

[bug #40639] GNU Make with profiling information

Follow-up Comment #6, bug #40639 (project make): Here is a new version of the patch. Author: Eddy Petrișor eddy.petri...@gmail.com Date: Tue Nov 19 05:14:40 2013 +0200 Now can choose profile format from predefined options Define 4 hard-coded profile printing formats which can

[bug #40639] GNU Make with profiling information

Additional Item Attachment, bug #40639 (project make): File name: profile-predefs-ga4937bc8.patch Size:9 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?40639 ___ Message sent

[bug #40639] GNU Make with profiling information

Follow-up Comment #7, bug #40639 (project make): Please check https://savannah.gnu.org/bugs/download.php?file_id=29801 instead of file #29800 ___ Reply to this item at: http://savannah.gnu.org/bugs/?40639

Re: [bug #40639] GNU Make with profiling information

Pe 25.11.2013 11:09, Reinier Post reinp...@win.tue.nl a scris: Can't this functionality be provided by a wrapper $SHELL? Sure, it's an extra exec(), but it will keep the make code base simpler. I'm not sure if I understand what you mean. Do you mean wrapping all target invokes in a

[bug #40639] GNU Make with profiling information

Follow-up Comment #3, bug #40639 (project make): I rebased the patch on top of f5f5adb6, updated to use O and OS macros, and strlist type for the -P/--profile/--profile-format option parameter. The patch is attached. (file #29698) ___

Re: [bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Pe 24.11.2013 18:41, Paul Smith psm...@gnu.org a scris: On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote: Since you just worked on this, and the new type overwrites in case of repetition, does it make sense to overwrite instead of error? I think that for profiling this type