When I say memory , I mean when make starts then in the main function I
have the getpid to give me the parent pid which I save in the env and that
is available to all the child processes so that I can find out when the
parent make has come into child handler by checking getpid == make pid from
env
On Sun, 2022-05-22 at 10:53 +0530, nikhil jain wrote:
> 1) write some content in a file only if the forked process ID is same
> as the main make process ID (stored main process ID in the memory as
> make starts so that it will be available to all the forked process).
I don't understand this. Yes
Never mind, Ignore it.
I figured it out.
Even the async signal safe API write() call was not writing to stdout
because the stdout was piped to "tee" command to a log file.
So, when a ctrl+c was generated, "tee" process also got it and it was
terminated, hence nothing got printed in the logs.
2 w
Thanks Paul, I know we can’t use standard C functions. The only reason I
wanted to check here is whether the parent make is also getting ctrl+c (
which it isn’t). Do you suggest calling die from within fatal signal
handler ?
My requirement is to perform a task( write to a file) only ONCE when I
g
On Sat, 2022-05-21 at 08:37 +0530, nikhil jain wrote:
> Also, fatal error handler in commands.C gets called multiple times. I
> believe it is getting called for each parallel make process the
> parent has invoked.
Certainly. When you press ^C make will propagate that signal to all
its children so
Hi guys,
I just tried the die function inside main.c
It did not get called when I ctrl + c a running make process. Please help
here.
Also, fatal error handler in commands.C gets called multiple times. I
believe it is getting called for each parallel make process the parent has
invoked.
Helpless
Thanks Paul, I will utilize the die() function! I already changed make to
be distributed. Thanks to the remote-stub.c (stub). I filled it in with my
logic of distributing the compiles across machines. Working fine since
couple of years! :)
Kaz, Yes you are right.
Unfortunately, as per the require
On 2022-05-05 11:07, nikhil jain wrote:
> Thanks Paul and Brian.
> I understand Now it's not possible to find out if it was an incremental
> build or a full build.
>
> What about the second question ?
>
> Before exiting make, I want to display the status of the build if it failed
> or passed.. ho
On Fri, 2022-05-06 at 00:14 +0530, nikhil jain wrote:
> My question is how do I print the exit status in the make itself
> before exiting make. May be at the last of main.c (main function) ?
> but how ? Which variable stores the exit code just before make exits
> ?
All exit paths of make go throug
Hi Brian,
I am not using -k.
My question is how do I print the exit status in the make itself
before exiting make. May be at the last of main.c (main function) ? but how
? Which variable stores the exit code just before make exits ?
Thanks
Nikhil
On Thu, May 5, 2022 at 11:48 PM Brian Cowan wro
Unless you have specified -k, a non-zero result from executing the build script
will cause make to terminate with a non-zero return code. If you use -k, I
would expect a non-zero return code from make even after the make continues. It
seems to do that in my rather stilted test… I’m not sure of t
"cache" tools (ccache?) that may give you at least
> SOME idea.
>
> -Original Message-
> From: Help-make On Behalf
> Of Paul Smith
> Sent: Thursday, May 5, 2022 12:54 PM
> To: nikhil jain
> Cc: help-make
> Subject: [EXTERNAL] Re: GMAKE 3.81 vs GMAKE 4.2
Paul Smith
Sent: Thursday, May 5, 2022 12:54 PM
To: nikhil jain
Cc: help-make
Subject: [EXTERNAL] Re: GMAKE 3.81 vs GMAKE 4.2
On Thu, 2022-05-05 at 21:41 +0530, nikhil jain wrote:
> Correct, but how do i know its a incremental or full ? any ENV is set
> which says it is incremental or full
On Thu, 2022-05-05 at 21:41 +0530, nikhil jain wrote:
> Correct, but how do i know its a incremental or full ? any ENV is set
> which says it is incremental or full ?
There's no possible way to know.
No make invocation will ever build every target in the makefile in any
real-world makefile (consi
Correct, but how do i know its a incremental or full ? any ENV is set which
says it is incremental or full ?
On Thu, May 5, 2022 at 9:38 PM Kaz Kylheku wrote:
> On 2022-05-05 06:42, nikhil jain wrote:
> > Hi Pablo,
> >
> > Thanks for your reply.
> > I actually do not know how many targets will b
On 2022-05-05 06:42, nikhil jain wrote:
> Hi Pablo,
>
> Thanks for your reply.
> I actually do not know how many targets will be compiled (we have more than
> 10k targets in a Makefile). So, is there a straightforward way to know that
> only a single code file is changed and it will be an incremen
Hi Pablo,
Thanks for your reply.
I actually do not know how many targets will be compiled (we have more than
10k targets in a Makefile). So, is there a straightforward way to know that
only a single code file is changed and it will be an incremental build and
not a full build ?
Regarding return v
You can do a run dry, which will print what recipes to run without running
them. From
https://www.gnu.org/software/make/manual/html_node/Instead-of-Execution.html
:
‘-n’
‘--just-print’
‘--dry-run’
‘--recon’
“No-op”. Causes make to print the recipes that are needed to make the
targets up to date, bu
Hi Guys,
I have been using gmake from a long time.
I wanted to know 2 things -
1) How do I know if the compilation is incremental or full ? I mean is
there a way in make to know that the compile is incremental ? Any variable
which is set ? any ENV variable ?
2) How do I know the status of the mak
Hi,
There are few like you said SGE's qmake. There is one from IBM called
lsmake but it needs LSF to run.
You can actually develop your own non-standard gmake build by filling out
the stubs in the remote-stub.c file. That will be much easier.
Thanks
Nikhil
On Sat, Jan 23, 2021 at 2:13 AM Cook, M
>The standard build of GNU make does not support any remote operations and
>it links in the remote-stub.c file which provides do-nothing versions of
>all the remote functions.
Is there a non-standard build that *does* support remote operations? I am
familiar with SGE's qmake. Is this such a bui
Any idea Paul and Team ?
On Thu, Jan 23, 2020 at 7:12 AM nikhil jain wrote:
> Ok thanks for the explanation.
>
> The issue here is the child has been reaped but when i print the Live
> child in job.c -
>
> DB (DB_JOBS, (_("Live child 0x%08lx (%s) PID %ld %s\n"),
> (unsign
Ok thanks for the explanation.
The issue here is the child has been reaped but when i print the Live child
in job.c -
DB (DB_JOBS, (_("Live child 0x%08lx (%s) PID %ld %s\n"),
(unsigned long int) c, c->file->name,
(long) c->pid, c->remote ? _(" (remo
On Tue, 2020-01-14 at 15:25 +0530, nikhil jain wrote:
> Hi Paul,
>
> I am coming across a strange issue in gmake.
> in Job.c there is a condition -
>
> /* Now try a blocking wait for a remote child. */
> pid = remote_status (&exit_code, &exit_sig, &coredump, 1);
>
> this pid is coming as -1 an
Hi Paul,
I am coming across a strange issue in gmake.
in Job.c there is a condition -
/* Now try a blocking wait for a remote child. */
pid = remote_status (&exit_code, &exit_sig, &coredump, 1);
this pid is coming as -1 and errorno set to 10 means no child.
But I had printed this -
DB (DB_JOB
Thank you Paul for the suggestions. Will think over them. Thanks for the
help.
On Tue, Dec 17, 2019 at 9:03 PM Paul Smith wrote:
> On Tue, 2019-12-17 at 20:44 +0530, nikhil jain wrote:
> > No, I do not want to delete the object file before sending the target
> > out. That's not how make should w
On Tue, 2019-12-17 at 20:44 +0530, nikhil jain wrote:
> No, I do not want to delete the object file before sending the target
> out. That's not how make should work or I should make it work.
That is simply not true.
In virtually all cases rebuilding a target will involve deleting the old
one in s
Have to check with the older team mates if they have added safe_stat by
themselves. Thanks to them. It works for my case atleast.
No, I do not want to delete the object file before sending the target out.
That's not how make should work or I should make it work. It is not make
issue. It is issue w
On Tue, 2019-12-17 at 13:17 +0530, nikhil jain wrote:
> A rule was processed and then as soon as it ends, the next dependent rule
> processed. It has to work on the object file generated by the first rule.
> But the timestamp of the file was older so the next rule did not process.
> I am on NFS.
I
This is what NFS specs says about it -
... to recover from an ESTALE error, an application must close the file or
directory where the error occurred, and reopen it so the NFS client can
resolve the pathname again and retrieve the new file handle.
And that is what safe_stat is doing - opening the
I will reply on this sooner with code snippets.
Just to again confirm that this actually solved a very critical issue in my
project,
A rule was processed and then as soon as it ends, the next dependent rule
processed. It has to work on the object file generated by the first rule.
But the timestam
On Wed, 2019-12-04 at 18:14 +0530, nikhil jain wrote:
> Just for information.
>
> Issue is not reproduced when replacing stat with safe_stat() which
> double checks the file for stale handle.
>
> On Wed, Dec 4, 2019 at 12:51 PM nikhil jain
> wrote:
> > A rule which executes in host A creates a .
Any comments?
On Wed, 4 Dec 2019, 18:14 nikhil jain, wrote:
> Just for information.
>
> Issue is not reproduced when replacing stat with safe_stat() which double
> checks the file for stale handle.
>
> thanks
> Nikhil
>
> On Wed, Dec 4, 2019 at 12:51 PM nikhil jain
> wrote:
>
>> Thanks for all
Just for information.
Issue is not reproduced when replacing stat with safe_stat() which double
checks the file for stale handle.
thanks
Nikhil
On Wed, Dec 4, 2019 at 12:51 PM nikhil jain wrote:
> Thanks for all the help. There was another script which was causing issue
> with the signal. I am
Thanks for all the help. There was another script which was causing issue
with the signal. I am able to catch the signal in make.
I successfully implemented the remote execution feature in make 3.81
I need some help.
My rules execute on different hosts on NFSi submit a job from host 1.
A rule wh
On Mon, 2019-10-21 at 22:47 +0530, nikhil jain wrote:
> see this how it works in makefile. It is part of the target -
>
> bash-4.1$ cat Makefile
> a1:
> trap 'USER_INT=1; /bin/echo "terminating, please wait"' INT; \
> sleep 100
>
> bash-4.1$ make
> trap 'USER_INT=1; /bin/echo
sorry to not be clear -
see this how it works in makefile. It is part of the target -
bash-4.1$ cat Makefile
a1:
trap 'USER_INT=1; /bin/echo "terminating, please wait"' INT; \
sleep 100
bash-4.1$ make
trap 'USER_INT=1; /bin/echo "terminating, please wait"' INT; \
s
On Mon, 2019-10-21 at 21:26 +0530, nikhil jain wrote:
> I handle SIGINT (ctrl+c) like this in the makefile -
>
> trap 'USER_INT=1; /bin/echo "terminating, please wait"' INT;
That is not valid makefile syntax. If you put that directly into a
makefile, by itself, you'll get a syntax error:
I handle SIGINT (ctrl+c) like this in the makefile -
trap 'USER_INT=1; /bin/echo "terminating, please wait"' INT;
This traps SIGINT.
Thanks
Nikhil
On Mon, Oct 21, 2019 at 6:09 PM Paul Smith wrote:
> On Mon, 2019-10-21 at 13:00 +0530, nikhil jain wrote:
> > I see that if I do a ctrl c then
On Mon, 2019-10-21 at 13:00 +0530, nikhil jain wrote:
> I see that if I do a ctrl c then fatal_error_signal function is
> called.
>
> Now the problem is if I am trapping ctrl c in makefile then
> fatal_error_signal is not called...
I don't know what you mean.
It's not possible to "trap CTRL-C in
Thanks, I will try that. I have one more question.
I see that if I do a ctrl c then fatal_error_signal function is called.
Now the problem is if I am trapping ctrl c in makefile then
fatal_error_signal is not called...
Is this expected?
I want to trap the signal in makefile to print the status.
On Mon, 2019-10-21 at 10:11 +0530, nikhil jain wrote:
> Alright, so I don't know much of the makefile stuff. But can it
> happen like a makefile is more optimized for a specific make version
> ?
> Can that happen at all?
I don't know how to answer this question in a useful way. Of course,
it's p
Alright, so I don't know much of the makefile stuff. But can it happen
like a makefile is more optimized for a specific make version ?
Can that happen at all?
On Mon, 21 Oct 2019, 09:05 Paul Smith, wrote:
> On Sun, 2019-10-20 at 23:59 +0530, nikhil jain wrote:
> > Is this expected ? Upgrading
On Sun, 2019-10-20 at 23:59 +0530, nikhil jain wrote:
> Is this expected ? Upgrading gmake comes with a hit on build time ?
No.
___
Help-make mailing list
Help-make@gnu.org
https://lists.gnu.org/mailman/listinfo/help-make
So,
Finally, I migrated all the code to GMAKE 3.81 from GMAKE 4.2 I noticed
that my build time is improved considerably in make 3.81 compared to make
4.2. Is this expected ? Upgrading gmake comes with a hit on build time ?
This is something not what i wanted but no other option. Thanks all for
On Sat, 2019-10-05 at 19:55 +0530, nikhil jain wrote:
> Can you tell when the make 4.3 will be official ?
Should be within a few weeks.
> If I share a makefile then can you debug that ?
Speaking for myself, I don't have the time to understand and debug
large makefile environments. If you can c
Thank you for explanation.
Actually these are legacy makefiles. Those who created them might not be in
the company even.
But still, we have asked R&D to find out what exactly makefile is doing and
why it is dependent on the sequence and how to avoid it.
Also, I have asked the user to create a min
On Fri, 2019-10-04 at 07:36 +0530, nikhil jain wrote:
> So it looks like the wild card issue as you mention.
If that is indeed the case, it means your build system is relying on
the sorted order of some files retrieved by wildcard in order to build
properly.
That's a problem: it makes your build
On 2019-10-03 19:06, nikhil jain wrote:
Just to confirm -
My build works with all the make versions. It's the binary which fails.
Then, I think, perhaps it would be good to avoid phrasing like
"build fails". Clearly, that is the opposite of "build works" that
you're using here.
With 3.81, ve
Just to confirm -
My build works with all the make versions. It's the binary which fails.
Binary works with only 3.81 and the alpha test release you gave.
It fails with versions starting from 3.82 to 4.2.
So it looks like the wild card issue as you mention.
Unfortunately there is one more issu
On Thu, 2019-10-03 at 20:54 +0530, nikhil jain wrote:
> Also, is there some change in how the commands will be displayed
> while running make.
>
> I saw some strange behavior -
>
> 1) Starting version 3.82, the builds are failing. They were
> successful in the latest alpha release of 4.2.91
> 2)
Also, is there some change in how the commands will be displayed while
running make.
I saw some strange behavior -
1) Starting version 3.82, the builds are failing. They were successful in
the latest alpha release of 4.2.91
2) Also till 3.81 the commands are being displayed properly when make is
Hi,
Thanks for the answers.
You know what!
It worked with GMAKE 4.2.91
It is the test version sent to me in the mail thread by a GMAKE expert. I
would probably move to it.
So, it looks like the wildcards issue then ?
thanks
Nikhil
On Tue, Oct 1, 2019 at 1:44 AM Christian Hujer
wrote:
> Hell
Hello Nikhil,
On Sat, Sep 28, 2019 at 1:54 AM nikhil jain wrote:
> I am seeing very different behaviors in my build between make version 3.81
> and 4.2
>
> My build compiles correctly but fails with segmentation fault on 4.2
> version.
> My build compiles correctly and executes also correctly on
RELAX!
I will do that. Thanks for your help. I will revert back with my findings
and ask for help if required.
Thanks
Nikhil
On Mon, Sep 30, 2019 at 9:23 PM Paul Smith wrote:
> It would be helpful if you could teach your email client to properly
> quote replies (or find a better one). Also we
It would be helpful if you could teach your email client to properly
quote replies (or find a better one). Also we prefer inline responses
rather than top-quoting.
On Mon, 2019-09-30 at 19:48 +0530, nikhil jain wrote:
> For example, maybe you're using $(wildcard ...) to gather filenames
> and the
On 2019-09-30 01:21, nikhil jain wrote:
Hi Tony,
1) I always set -j 4.
2) No, I do not set -l flag.
3) The BUILD never fails. The binary which is generated causes
segmentation
fault. It works perfectly If I build in 3.81 GMAKE.
Possibly, what is going on that you have some $(wildcard ...) ma
For example, maybe you're using $(wildcard ...) to gather filenames and
the difference in the order returned is causing your code to be linked
differently (in 3.81 I believe wildcard also sorted output while in
4.2.1 it doesn't--however in 4.3 it will again).
Do you confirm the above behavior can
On Mon, 2019-09-30 at 13:51 +0530, nikhil jain wrote:
> There are 2 parts to this problem -
>
> 1) Build the code using v3.81 and v4.2 -> In both cases, builds is
> happening correctly.
> 2) Segmentation fault -> While running the binary generated from the build,
> it segfaults with v3.81 and work
Hi Tony,
1) I always set -j 4.
2) No, I do not set -l flag.
3) The BUILD never fails. The binary which is generated causes segmentation
fault. It works perfectly If I build in 3.81 GMAKE.
4) Makefile is handwritten.
5) No, It never succeed on any number of invocation.
Just to again notify -
Ther
> On 28 Sep 2019, at 16:21, nikhil jain wrote:
>
> Do you mean to not use -j ?
>
> That means a single rule execution at a time. It takes 2 hours to build.
> With -j4 it takes 1 hour.
>
> I have -j kind of unlimited. So it usually takes around just 5 minutes to
> build. Less than that sometim
Do you mean to not use -j ?
That means a single rule execution at a time. It takes 2 hours to build.
With -j4 it takes 1 hour.
I have -j kind of unlimited. So it usually takes around just 5 minutes to
build. Less than that sometimes.
What exactly is the bug ? And what is the fix in 4.2 ?
Thanks
On 2019-09-27 13:23, nikhil jain wrote:
Please reply. It is urgent for me to provide a Correct compiled product
to
my users.
I do not want to switch back to 3.81.
Could this be related to parallelization with "-j "?
If you put a
.NOTPARALLEL:
declaration at the top of your Makefile, does t
63 matches
Mail list logo
