"Erich Boleyn wrote:"
With a Bourne style shell you can pass what you want to the environment
as done below.
>
> Summary:
> Environment variables set in the Makefile do not get inherited
> into anything run via the "shell" subcommand.
>
> Tested on GNU Make versions:
> 3.81 (o
"Paul Smith wrote:"
>
> On Wed, 2014-07-23 at 08:37 -0700, David Highley wrote:
> > Cross post from make-w32. Trying to find out if this is a known issue
> > and or if there is a fix in the works.
>
> Sorry, I was on vacation.
Sorry, I should have updated with
Foo bar, I see that I left out one macro definition.
>
> Cross post from make-w32. Trying to find out if this is a known issue
> and or if there is a fix in the works.
>
> Using make version 4.0-2 current version in cygwin version 1.7.31. We
> have on make process that works with make 4.0 on Linu
Cross post from make-w32. Trying to find out if this is a known issue
and or if there is a fix in the works.
Using make version 4.0-2 current version in cygwin version 1.7.31. We
have on make process that works with make 4.0 on Linux.
The make log provides:
cd ../CommonCode/src && "make"
make[1]:
"Van de Bugger wrote:"
>
> Follow-up Comment #2, bug #40431 (project make):
>
> Thanks, I also found this trick independently. Unfortunately the trick does
> not work. Or, stricly speaking, it works, but there is an unwanted side effect
> which makes it useless. Look:
>
> # Note: in current shel
"Jonathan Nieder wrote:"
>
> Hi Paul et al,
>
> Vincent Lefevre wrote[1]:
>
> > Debugging would be much easier if all commands are echoed (i.e.
> > including those starting with '@') with "make -d". I suggest
> > adding the --debug option "e (echo)" for this purpose.
>
> Sounds like a good idea
"David Highley wrote:"
>
> "Philip Guenther wrote:"
> >
> > Looking backwards, this rule from your top level makefile:
> >
> > > $(INF_DIST_SVCS_OBJS): $(DIRS)
> >
> > seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list
"Philip Guenther wrote:"
>
> Looking backwards, this rule from your top level makefile:
>
> > $(INF_DIST_SVCS_OBJS): $(DIRS)
>
> seems bogus, given that $(INF_DIST_SVCS_OBJS) is a list of objects in
> directories _below_ the list of directories in $(DIRS). The top level
> make may recurse, then
"Philip Guenther wrote:"
>
> On Thu, Oct 7, 2010 at 9:22 AM, David Highley
> wrote:
> ...
> > Let us just cut to the essence of the issue we are running into, how do
> > target prerequisites get processed in version 3.81 of make?
> >
> >
that would matter in the
context of understanding how the prerequisites are processed.
"David Highley wrote:"
>
> Well, I'm going to have to eat crow on this one. After much digging into
> this issue, down loading older versions of make back to 3.78.1.
> Researching ou
latest version 3.82 down loaded from savannah.gnu.org and it
also does not work. Let me know how I can further support getting this
issue fixed.
"Paul Smith wrote:"
>
> On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote:
> > The latest version of Fedora 13 does not have a 3
"Paul Smith wrote:"
>
> On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote:
> > The latest version of Fedora 13 does not have a 3.82 verion of make so
> > the only way to test would be to build from source which I can do. It
> > may take me a whil
"Paul Smith wrote:"
>
> On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote:
> > Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the
> > issue we are running into. Now to find the right version for Cygwin.
>
> I'd be really intere
"David Highley wrote:"
>
> "Edward Welbourne wrote:"
> >
> > > Every time the subject of cache comes up its because they are always
> > > wrong.
> >
> > well, this *is* a *bug* list - every time anything comes up here, it's
>
"Edward Welbourne wrote:"
>
> > Every time the subject of cache comes up its because they are always
> > wrong.
>
> well, this *is* a *bug* list - every time anything comes up here, it's
> because someone's found a bug in it ! The vast amount of the time
> that the cache works just fine and make
"Edward Welbourne wrote:"
>
> > it appears from running make with the debug option that the
> > top level make does not see the object file created by the lower level
> > make in the time when it checks the dependencies for the library.
>
> sounds a *lot* like an issue with make's caching of stat
We have a build process that had no issues in the past when we were on
Red Hat 3 and an older version of Cygwin. Now our core library builds
fail to link intermittently on a rebuild when building on Red Hat 5.1
and Windows using Cygwin make and Windows compilers. I did some digging
into it today a
17 matches
Mail list logo
