"Exception handling" ?

I wonder if anyone has ever wanted the ability to "handle" the failure of a rule? I needed it so that I could produce various types of log information when a compile/link step failed. I have used some ugly macros to wrap my rules in a bash subshell so that I can catch the return result, perform

Re: GNU make to consider files checksum

Hi, I am also not a maintainer :-). One small concern that I have with checksums is that it might take a really long time to check large files or a lot of files. This would indicate that one needs to be able to switch checksumming on/off for different prerequisites. I think that there should be

Fwd: Help : how to use $(or condition ) & $(and condition ) in makefile

Sorry, forgot to send this to bug-make as well. -- Forwarded message -- From: Tim Murphy <[EMAIL PROTECTED]> Date: 2008/6/6 Subject: Re: Help : how to use $(or condition ) & $(and condition ) in makefile To: [EMAIL PROTECTED] Hi, # do "equal" by seeing if

Re: Help : how to use $(or condition ) & $(and condition ) in makefile

Hi, I have amended an example of how to use $(and) that I posted earlier for Rakesh. I have tested this on Linux with make 3.81. It shows a crude way and a slightly more sophisticated way to use $(and) in an if statement to determine if two variables have equal values: A=2 > B=4 > > # do "equal

Re: Help : how to use $(or condition ) & $(and condition ) inmakefile

PROTECTED]>: > Try make -f and.mk A=22 B=44. > > > -- > > *From:* [EMAIL PROTECTED] [mailto: > bug-make-bounces+mdorey [EMAIL PROTECTED] *On > Behalf Of *Tim Murphy > *Sent:* Tuesday, June 17, 2008 09:31 > *To:* bug-make@gnu.org > *Su

Re: Enhancement request: Watch source files for changes

I'm just another make user. I like the idea - some operating systems have change notification mechanisms. One could use this for a kind of continuous integration - rebuilding files as they are changed or checked in. Putting make in an internal loop would be pointless - one might as well write th

Re: [bug #25751] Add option to output dependency info as xml

Hi, This is very interesting. I have used emake with Electric Accelerator and it's a pretty amazing system but I was just wondering why you need to generate XML since emake can read gnu makefiles pretty accurately already? I obviously don't understand your posting properly so please don't think

Fwd: error make

-- Forwarded message -- From: Tim Murphy Date: 2009/4/12 Subject: Re: error make To: Richard Alexis Gomez Medina Hi, This is not a problem with gnu make but with the driver that you are trying to compile or with the kernel that you are compiling it for. To me it looks like

Re: make 3.81 + i386-pc-interix* parallelism problem, and "write error"

Hi, I'm not a maintainer or anything but I have hacked around in the bit of code that implements the job-server. It's complicated and in my case I realised that I actually didn't want it at all so I compiled make without it. Do you really need it? Do you use sub-makes (i.e. do you have makefiles

Re: make 3.81 + i386-pc-interix* parallelism problem, and "write error"

Hi 2009/5/6 Markus Duft : > On Wed, 2009-05-06 at 09:02 +0100, Tim Murphy wrote: >> Do you really need it? Do you use sub-makes (i.e. do you have >> makefiles that call make again on other makefiles)? > > hmm. we're using automake, so i guess yes, every subdir is man

Re: Why "*** extraneous `endef'. Stop."?

Hi, define starts a macro. Everything from the start of the macro to endef is just text and is not evaluated. So your inner "define" is not recognised - it's just treated as text. That means that the dirst endef matches the first define and all the other endefs seem to have no corresponding defi

Why "*** extraneous `endef'. Stop."?

-- Forwarded message -- From: Tim Murphy Date: 2009/9/6 Subject: Re: Why "*** extraneous `endef'. Stop."? To: a...@gnu.org Oh dear - sorry - I'm an idiot. All I can say is that the ifneq statement is what makes it go wrong for me.  Using $(if works for me

Re: GNU make to consider files checksum

Hi, I think that checksumming might benefit some targets. It would be nice to be able to implement different "methods" for different targets - because not all methods work well in all circumstances. I have one example where every single file in a huge build includes 1 particular header file. Th

Re: GNU make to consider files checksum

Hi :-) 2009/10/5 : > > Tim Murphy wrote: >> I think that checksumming might benefit some targets.  It would be >> nice to be able to implement different "methods" for different targets >> - because not all methods work well in all circumstances. > >> I

Re: Prioritizing non-dependent targets in parallel make

Hi, I'm nobody official. I have seen Electric Accelerator using history files which may be doing something a bit like this. Personally I don't like the idea of priorities very much. Large builds that I have done do have big targets but since we are building 5000 of the same kind of target (usin

Re: Prioritizing non-dependent targets in parallel make

2010/1/4 Eric Melski : > > Hi Tim! > > ElectricAccelerator doesn't factor runtimes into scheduling decisions, > although we have talked about doing so in the past.  I spent some time > investigating the possibility, most recently a couple years ago.  What I did > was tweak the Simulator report in E

Re: [RFC]serialize the output of parallel make?

Hi, Serialisation can be done by external programs - no real need for make to do it. My project does it already with the talon shell wrapper that we use in our build system here: http://developer.symbian.org/oss/MCL/sftools/dev/build/file/96fee2635b19/sbsv2/raptor/util/talon You set talon as th

Re: [RFC]serialize the output of parallel make?

On 30 July 2010 09:55, Chiheng Xu wrote: > On Fri, Jul 30, 2010 at 4:40 PM, Tim Murphy wrote: >> Hi, >> > >> >> You set talon as the shell for make and talon in turn runs whatever >> the actual shell is but adds the serialisation.  there are a lot of >&

Re: [RFC]serialize the output of parallel make?

Hi, One of the major problems with log output that is interleaved is that you cannot tell what went wrong in your build because errors become disassociated with the recipe that they belong to. Some compilers etc get away with this because there is enough information in a single line of error outp

Re: Fwd: [RFC]serialize the output of parallel make?

Hi, Since some things happen at the same time there is no single "serial order". The semaphore mechanism, forces one of the possible orders. I forgot to say that for recipes with multiple commands you need to either use the new .ONESHELL target or do this kind of thing: mytarget:mytarget: ->com

Fwd: Import statement - non-recursive make implementation

Sorry - messed up the reply-to-all. -- Forwarded message -- From: Tim Murphy Date: 7 September 2010 15:12 Subject: Re: Import statement - non-recursive make implementation To: psm...@gnu.org Hi, I think I can guess and if I'm wrong then please ignore this. One wants to

Re: Fwd: Import statement - non-recursive make implementation

Why didn't you do this 4 years ago darnit? ;-) Cheers, Tim On 7 September 2010 17:40, Kamil Mierzejewski wrote: > Hi, > > Tim, your explanation of the problem is exactly what I want to deal with, > and... > >> Does this change sort that out so that: >> 1) all the little sub-makefiles can have p

Re: patch to support output synchronization under -j

File locking would be the exclusion mechanism with a shell implementation, right? With Talon we used a system semaphore with timeout-wait semantics . I would assume that one doesn't need it if the code is in make since make can choose when to start and stop reading from any particular file handle

Fwd: patch to support output synchronization under -j

-- Forwarded message -- From: Tim Murphy Date: 14 April 2011 20:43 Subject: Re: patch to support output synchronization under -j To: psm...@gnu.org The reason for splitting stderr and stdout is to do with deadlock and reading pipes. IIRC.  e.g. blocking on a read to stderr which

Re: patch to support output synchronization under -j

That was a confused email - apologies. I will rethink it and return. :-) On 14 April 2011 20:43, Tim Murphy wrote: > -- Forwarded message -- > From: Tim Murphy > Date: 14 April 2011 20:43 > Subject: Re: patch to support output synchronization under -j > To:

Re: patch to support output synchronization under -j

up. How do you know what order they should be in in the output? SeS, SSe or eSS? So one theory goes -ah forget it. Regards Tim On 14 April 2011 20:46, Tim Murphy wrote: > That was a confused email - apologies.  I will rethink it and return. :-) > > On 14 April 2011 20:43, Tim Murp

Re: patch to support output synchronization under -j

hat method one uses) but that's not generally such a problem. Regards, Tim On 14 April 2011 21:18, Paul Smith wrote: > On Thu, 2011-04-14 at 20:59 +0100, Tim Murphy wrote: >> To prevent any kind of deadlock you sort of want to empty everything >> the stderr and stdout pipe

Re: patch to support output synchronization under -j

I replied to this without using "reply all" and I apologise. :-) The order of the output from separate recipes may be anything - depends on how make schedules them but at least the output from any particular recipe will be grouped together and not mixed with the output from others, hence allowing

Re: patch to support output synchronization under -j

> What about the other issue: with the fact that output from a recipe is > only shown when the entire recipe is done. I think this is a serious > drawback, at least in some use cases. Can anything be done about > that? The only thing that I can imagine is that one would allow one recipe to have

Re: patch to support output synchronization under -j

I wish I could play with one of those Connection machines and find out about the bottlenecks at j=0.25*cpus that I can see on some machines :-( Regards, Tim On 15 April 2011 19:32, Howard Chu wrote: > Eli Zaretskii wrote: >>> >>> Date: Fri, 15 Apr 2011 10:37:13 -0400 >>> From: David Boyce >>> i

Re: patch to support output synchronization under -j

On 3 May 2011 17:39, Eli Zaretskii wrote: > That was exactly the scenario I had in mind when I wrote my message. > Recursive Makefiles are the rule nowadays, at least with GNU software, > and the top-level Makefile does little more than launch a "make all" > job in each subdirectory.  GCC or GDB

Re: New Feature Submission for GNU Make

I would rather see a heck of a lot of new functions actually. I am really fed up with some of the limitations of gnu make as it is that might be solved very easily with even 1 or two well chosen new ones. Perhaps a warning when one redefines an internal function might be the way to avoid throttlin

Re: suggestion: new make function

My apologies to Luke for forgetting "reply to all" and for forgetting my manners by using the word "sucks" when I should not have. > I vote 'no'. This can easily be implemented in your > Makefile. (assuming no single list item breaks the limit) > > dumpOneLine = $(foreach item,$(2),echo -n '$(item

Re: [rfc] Colorized output for GNU make?

Hi, I have no decision making abilities so this comment is just an observation I think that being able to wrap make output in strings such as codes to set/unset colours or tags so that a parser can distinguish it would be quite interesting. My personal preference would be to see things the other

Re: make error

Your makefile is trying to execure a directory rather than a program. Cheers, Tim On 5 October 2011 15:48, Carolina Carneiro wrote: > Hi, > > I'm trying to use make to compile the drivers of a program I have to use, > called MOCASSIN. > But when I type make mocassin, this error menssage appears

Re: make error

im On 5 October 2011 16:16, Paul Smith wrote: > On Wed, 2011-10-05 at 16:07 +0100, Tim Murphy wrote: >> Your makefile is trying to execure a directory rather than a program. > > Hah!  I didn't even notice it was a directory.  Good catch. > > I'm having a really bad week.

Re: 'withfile' function implementation

Just a quick comment on this. I looked at the implementation and it seems like a different name would suit this function - e.g. "writefile". It basically writes text from it's arguments out to a file. The idea of a function called "withfile" seems hard to actually implement - I'm not sure how on

Re: 'withfile' function implementation

I think that looks ok. There might be some question about how the variable "$(FILE)" would look if you tried to iterate over its contents. e.g. would one see an iteration for each word and with "\n"s marking lines or is each line an "atom" for want of a better word. Regards, Tim 2012/1/16 Paul

Re: [bug #35485] New $(.MFDIR) built-in variable

Hi, I know this is tangential, but: MAKEFILE_LIST itself is a problem for non-recursive builds because it gets very big if you have a lot of include statements (as opposed to a gigantic single makefile file). Regards, Tim On 8 February 2012 18:30, David Boyce wrote: > URL: >  

Re: [bug #35485] New $(.MFDIR) built-in variable

rds, Tim On 9 February 2012 14:37, David Boyce wrote: > On Thu, Feb 9, 2012 at 5:33 AM, Tim Murphy wrote: >> Hi, >> >> I know this is tangential, but: >> >> MAKEFILE_LIST itself is a problem for non-recursive builds because it >> gets very big if you have a l

Re: Dump the database to a makefile and invoke make on the dumped makefile.

Hi, This can be done and we have tried something similar for exactly the same reasons. It wasn´t utterly trivial for us for a number of reasons but in your case you might not have the same problems. We were trying to pre-parse the makefile in parallel then read the parsed version. We didn try t

Re: Dump the database to a makefile and invoke make on the dumped makefile.

d. Working well on the micro scale is sometimes at odds with working well at the macro scale and an ideal make tool would somehow help one to deal with that without one having to maintain different and very complicated makefiles for each situation. Regards, Tim On 26 February 2012 19:51, Paul Sm

Patch to allow make to load plugins that add new functions.

Hi, I am between jobs which made me realise that I am absolutely free to contribute to make for about 10 days :-) The one thing I have wanted the most and the longest is a way to add new functions without having to rebuild and look after a custom version of make. Essentially this should allow pe

Re: Patch to allow make to load plugins that add new functions.

rds, Tim > -Original Message- > From: bug-make-bounces+libarria=nvidia@gnu.org > [mailto:bug-make-bounces+libarria=nvidia@gnu.org] On Behalf Of Tim Murphy > Sent: Thursday, April 05, 2012 2:51 AM > To: bug-make@gnu.org > Subject: Patch to allow make to load plugins that

Re: Patch to allow make to load plugins that add new functions.

Hi, On 5 April 2012 23:12, Paul Smith wrote: > Hi Tim; > > Before going too much further note that I've got a semi-implemented > "load" operator in my source already, which fulfills a similar function > except in a less sophisticated way: it just calls a function in the > loaded object after load

Re: Patch to allow make to load plugins that add new functions.

an environment variable. I am initialising the plugins quite early but I don't think that it's critical to do so - hence adding syntax is quite possible. I was trying to avoid doing that because it's always so controversial but since Paul already has a plan for syntax... Regards

Re: Patch to allow make to load plugins that add new functions.

Hi :-) On 6 April 2012 01:16, Paul Smith wrote: > On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote: >> I see the value in a plugin system as being that I don't have to >> recompile the plugins for every version of make. In a way it's tending >> towards "wh

Re: Patch to allow make to load plugins that add new functions.

On 6 April 2012 21:55, Eli Zaretskii wrote: >> From: Paul Smith >> CC: David Boyce , bug-make@gnu.org >> Date: Fri, 6 Apr 2012 16:13:47 -0400 >> >> Maybe this is just irrational prejudice but I've never had a good >> experience using libtool and I'm SO uninterested in fighting with it in >> GNU m

Fwd: How to get make result

Hi, Use the -n option. make -n This shows what would happen but doesn't do anything.  It's not precisely what you want but it's the closest thing. Regards, Tim On 1 May 2012 10:46, ?? wrote: > Hello, my english not vell. > I try to explain my tack. > I need go get file names

Re: Patch to allow make to load plugins that add new functions.

Knowing make's current idea of where it is would still be nice even if it keeps changing. I also would like to hook to the start and end of the execution of every recipe because there are many uses for this, one of which might be progress but triggering retries (when unreliable network shares are

Re:[bug #17873] .NOTPARALLEL enhancements

Using targets to make subdirectories is problematic, imho, since the timestamps on the directory don't have any particular meaning. This is a case of recursive maake being harmful. If it was me, the dependency would be on the .a file, not on the directory. all: $(TARGETS) Target1: adir/lib1.a b

Re: Feature request: silently overriding existing rules

This is a different thing but I'd have had great use for a way to tell if a target had been defined previously. Had to use variables to do it which used a lot of memory and it was a total waste because make has the information already. Perhaps the ability to detect if a target is defined and anoth

Re: Feature request: silently overriding existing rules

" wrote: > On 08/11/2012 07:36 AM, Tim Murphy wrote: > > This is a different thing but I'd have had great use for a way to tell > if a > > target had been defined previously. Had to use variables to do it which > > used a lot of memory and it was a total w

Re: Patch to allow make to load plugins that add new functions.

Hi :-) This is a response to a rather old email about loadable modules. I'm keen to see the patch for the load operator if you have it :-). On 5 April 2012 15:12, Paul Smith wrote: > Before going too much further note that I've got a semi-implemented > "load" operator in my source already, whi

Re: Dependency violation in parallel build (3.82, regression)

It would be nicest to actually use git (or if we were in heaven, Mercurial)! :-) Cheers, Tim On 3 January 2013 20:20, Frank Heckenbach wrote: >> > BTW, I wanted to check against the current repository version, but >> > when I tried to fetch it as described on >> > https://savannah.gnu.org/git/?

Re: Quirk with rules producing multiple output files

There are commercial emulations of GNU make that can handle multiple outputs. I don't want to plug them because that might be annoying. It's just worth mentioning that it can be done. Regards, Tim On 11 April 2013 11:14, Reinier Post wrote: > On Thu Apr 4 16:17:58 2013, psm...@gnu.org (Paul

Re: Quirk with rules producing multiple output files

ind a better explanation than I can give. Regards, Tim On 11 April 2013 19:35, David Sankel wrote: > On Thu, Apr 11, 2013 at 12:31 PM, Tim Murphy wrote: > >> There are commercial emulations of GNU make that can handle multiple >> outputs. I don't want to plug them becaus

Re: [bug #33138] .PARLLELSYNC enhancement with patch

o see where one rule ended and the next one began. When most rules are a single job this doesn't seem important but when you're doing anything non trivial it becomes hard to see what is where. Regards, Tim On 16 April 2013 09:56, Tim Murphy wrote: > This is an awesome feature, esp

Re: [bug #33138] .PARLLELSYNC enhancement with patch

_OUTPUT=endrule $@ $(timestamp) Then I'd use my plugin skills to write a $(timestamp) function. Regards, Tim On 16 April 2013 13:43, Paul Smith wrote: > On Tue, 2013-04-16 at 09:57 +0100, Tim Murphy wrote: > > When most rules are a single job this doesn't seem important but

Re: [bug #33138] .PARLLELSYNC enhancement with patch

Some time ago when solving the same problem in a different way we used semaphores on Windows and Linux. Compatibility might make it less interesting but I would suggest pretending that one has semaphores first with some nice little abstraction and then implementing them in the best way the platform

Re: [bug #33138] .PARLLELSYNC enhancement with patch

why not use a named semaphore wherever possible (windows and linux) and lock a file where not instead of trying to pass kernel object handles around (seems a bit nasty to me)? On 24 April 2013 21:19, Paul Smith wrote: > On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote: > > > Nothing is ac

Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

-- Forwarded message -- From: Tim Murphy Date: 25 April 2013 07:13 Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch To: "Paul D. Smith" To be honest, I have done all this before with named semaphores including the "file that gets left over"

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

ugh. Regards, Tim On 25 April 2013 19:12, Paul Smith wrote: > On Thu, 2013-04-25 at 07:14 +0100, Tim Murphy wrote: > > To be honest, I have done all this before with named semaphores > > including the "file that gets left over" problem and it's all solvable > >

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

On 25 April 2013 20:06, Eli Zaretskii wrote: > > Date: Thu, 25 Apr 2013 19:36:28 +0100 > > From: Tim Murphy > > Cc: "bug-make@gnu.org" > > > > 1) sem_timedwait() in posix lets you timeout so in a big build when > > something crashes or jus

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

Let me add my voice as a user. If you are one of the lucky people whose builds consist mostly of 1 line of output per rule then you will rarely have any trouble in a good build but try interpreting error messages from compiler/tool X when they're 10 lines from the file that they refer to and don't

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

On 29 April 2013 16:19, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 09:58:50 +0100 > > From: Tim Murphy > > Cc: "bug-make@gnu.org" > > > > try interpreting error messages from compiler/tool X when they're 10 > > lines from the file that

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

Sorry to keep adding in my 2c but I have also submitted a plugin implementation so I have a couple of ideas On 29 April 2013 17:33, Eli Zaretskii wrote: > > 2. The fact that the dynamic object's file extension (.so) is exposed >to the Makefile is unfortunate, because it will hurt portabilit

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

gt; > Date: Mon, 29 Apr 2013 16:40:03 +0100 > > From: Tim Murphy > > Cc: "bug-make@gnu.org" > > > > cc fred.c -c -o fred.o > > cc bob.c -c -o bob.o > > error on line 20 -X > > > > Which one? > > Make will actually tell you w

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

I must clarify - I think that make should provide plugins with an allocation mechanism. Not the other way around. the snprintf model for dealing with expansion is not so bad - I mean the problem is that nobody knows how big an expansion is going to be in the end, right? So how does make deal wit

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

Guenther wrote: > On Mon, Apr 29, 2013 at 10:30 AM, Tim Murphy wrote: > > cc fred.c -c -o fred.o > > cc bob.c -c -o bob.o > > error on line 20 -X > > error on line 30 - > > error on line 330 - > > makefile:342: recipe for target 'fred.o

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

wrote: > > Date: Mon, 29 Apr 2013 19:33:10 +0100 > > From: Tim Murphy > > Cc: Eli Zaretskii , "bug-make@gnu.org" > > > > Come now - the broken excuse is an excuse. There's plenty of crap free > > software out there and some poor bastard trying

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

On 29 April 2013 20:12, Eli Zaretskii wrote: > > Date: Mon, 29 Apr 2013 18:19:09 +0100 > > From: Tim Murphy > > Cc: "Paul D. Smith" , "bug-make@gnu.org" < > bug-make@gnu.org> > > > > > 2. The fact that the dynamic object's file

Re: dynamic object searching (was: Re: Dynamic objects)

s, Tim On 30 April 2013 03:38, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: Tim Murphy , bug-make@gnu.org > > Date: Mon, 29 Apr 2013 16:34:01 -0400 > > > > On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote: > > > > > > Yes, that s

Re: Some serious issues with the new -O option

I'm guessing here but I imagine the main problem comes with delaying the results of submakes? I haven't tested to see if this is how the new feature works or not. I don't think it's completely necessary to keep all output from one submake together. so turning that off might make things more intera

Re: Some serious issues with the new -O option

What I mean is that: ./make -Otarget might be a good interactive default rather than -Omake. Colouring is another issue which I would imagine could be done another way to let us have the best of both worlds. Regards, Tim On 30 April 2013 10:55, Tim Murphy wrote: > I'm guessing he

Re: Some serious issues with the new -O option

t the log of a build you did yesteday? It's still very nice to be able to distinguish things by colour later on. Regards, Tim On 30 April 2013 11:16, Stefano Lattarini wrote: > On 04/30/2013 12:01 PM, Tim Murphy wrote: > > What I mean is that: > > > > ./make -

Re: dynamic object searching (was: Re: Dynamic objects)

On 30 April 2013 17:28, Eli Zaretskii wrote: > > > Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit > > program, the real issue is what architecture was make itself built with. > > That's unrelated. I was talking about the fact that > > load foo.so > > is inherentl

Re: dynamic object searching (was: Re: Dynamic objects)

make second guessing your decisions. Regards, Tim On 30/04/2013, Paul Smith wrote: > On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote: >> i.e. I don't just have >> load X.dll > >> I have to supply the recipe to build it on windows: > >> X.dll: >>

Re: Some serious issues with the new -O option

One optimisation I have thought of in the past for this situation would be to allow a single "job" to hold onto the lock when it obtained it. This way it could output directly to the console while all other jobs would have to buffer. When it released, the next job lucky enough to grab the lock mi

Re: Another issue with -O?

I've done the "external utility" solution and only because we absolutely had no other choice - it's not much fun and can be done much more effectively by make itself. Regards, Tim On 3 May 2013 14:16, Eli Zaretskii wrote: > > From: Paul Smith > > Date: Fri, 03 May 2013 08:57:57 -0400 > > Cc:

load directive - module parameters

One thing that's worth thinking about in advance about the load directive is whether there needs to be a way to pass parameters into modules. In my case I need for the module to be able to know whether it's allowed to generate debug output or not. I can think of many other areas in which I might

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

spaces-for-tabs bugs are pretty common and very annoying though. If it's not your editor then it's some stupid website or wiki page that one puts example makefiles into. Or one types the example but theres no way to insert a tab since it takes you to the next field. Then people cut and past the

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

ah, interesting - good point. My standard (at least the enforced standard where I work) is 4-spaces and it doesn't catch that. On 5 September 2013 10:44, Eli Zaretskii wrote: >> Date: Thu, 5 Sep 2013 10:38:16 +0100 >> From: Tim Murphy >> Cc: Byron Hawkins , >>

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

d finally enforcement of something. Regards, Tim On 5 September 2013 11:18, Tim Murphy wrote: > ah, interesting - good point. My standard (at least the enforced > standard where I work) is 4-spaces and it doesn't catch that. > > On 5 September 2013 10:44, Eli Zaretskii wrote:

Fwd: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

forgot to cc the list - oops. -- Forwarded message -- From: Tim Murphy Date: 5 September 2013 14:30 Subject: Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens To: "Paul D. Smith" warning and finally enforcement of

Re: [bug #40225] Deterministic output ordering

I think this is something that's difficult to do and somewhat beside the point. It's lucky if you're someone for whom two builds even have all the same targets or all the same dependencies. The idea of diffing 2 builds is truly a cool one - especially when they're huge - but I'd rather it was don

Re: [bug #40225] Deterministic output ordering

while the >> rest of the build runs, ready for the next incremental. > > Of course, for similar reasons we now have different levels of > output-sync, and that's why I think ordering can be seen as yet > another one of those levels. > > Tim Murphy wrote: > >> The

Re: [bug #40225] Deterministic output ordering

> Me too. I think we all basically agree that all of the above can be > useful, we just disagree on how hard each is to implement. I'm not > so sure these "very few little enabling features" are really such > small changes, whereas I think ordered output and/or individual log > files are easier to

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

FWIW As for profiling output, this should probably go to a file (possibly with a .PID on the end) , not stdout .unless. you start to embrace the idea of structured output for everything that make produces. I have used XML before and it has advantages, not the least of which is that it is

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

prints out something similar to what I'm looking for. I also like it when the format is such that it can change a bit without necessarily forcing me to rewrite my parser. Again, this is only an opinion - it carries no weight. Regards, Tim On 29 November 2013 02:43, Eddy Petrișor wrote: >

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

seconds where the precision might vary depending on the architecture and OS. Anyhow it's just my 2p. Cheers and merry christmas, Tim On 15 December 2013 09:00, Eddy Petrișor wrote: > > Pe 29.11.2013 12:30, "Tim Murphy" a scris: > > >> >> When I

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

arge build system and it was easy to parse and produced a lot of useful data for us which would have been exceedingly difficult to do without a structured output format. Cheers, Tim On 15 December 2013 13:38, Tim Murphy wrote: > I suppose I'm skirting around saying that I think gnu make

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

On 15 December 2013 16:07, Paul Smith wrote: > In other words, I prefer to take a page from Git, GDB, and other > projects where the default output is human readable but probably not > easily parsed by tools, and then provide a different output format > option that provides machine-parse-able for

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

It's nice to know when in the build a job was scheduled. e.g I have a huge job that gets scheduled at the end of the build - wouldn't it be nicer if it was scheduled at the beginning? Perhaps I can redesign my makefile to achieve that if I know. On 11 January 2014 18:58, Paul Smith wrote: > Sorr

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

To some, using a spreadsheet might not seem like the most worthwhile way to visualise timing information. If it was me, I'd be far more concerned about whether I could write a script that could easily cope with all this information. Builds with hundreds of thousands of targets were common for me

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

E and then use that in every submake to get the relative start time. I haven't looked at the patch - perhaps it's doing this? In any case, fixed/floating point seconds since 1970 is the nicest format to process from scripts in my experience. Regards, Tim On 14 January 2014 15:49, Tim Murp

Re: Bug-make Digest, Vol 135, Issue 17

On 24 February 2014 18:33, Paul Smith wrote: > I would definitely want this to be totally invisible to the user and not > require any magic in makefiles (so no special include operator, etc.) > Basically it should either be so safe that there's no way to tell the > difference between using the co

Re: compile using make!

We cannot help you if you don't post your makefile. Every makefile is different and nobody can give you an answer that is guaranteed to work without seeing it. You might be lucky if you set LDFLAGS e.g. to "-lmysqlcppconn" but this could easily not be correct. Regards, Tim On 20 June 2014 07:37

Re: [PATCH v2 1/6] * expand.c (variable_name_extract): extract variable name and strip prefix.

This sounds like an extremely useful debugging feature. I have often had the problem of getting the wrong build parameters but not being sure exactly why because of the great complexity of makefiles that are trying to build many different sorts of object files all with slight variations that are

Fwd: Dynamic adjustments of build dependencies for the number of available processors

-- Forwarded message -- From: Tim Murphy Date: 5 January 2015 at 17:20 Subject: Re: Dynamic adjustments of build dependencies for the number of available processors To: SF Markus Elfring Hi On 5 January 2015 at 17:03, SF Markus Elfring wrote: > > > I'm sor

  1   2   >