List Info

Thread: Jam newer bug on OSX




Jam newer bug on OSX
country flaguser name
United States
2007-02-28 20:02:17
I seem to have run into a bug in timestamp checking on OSX.
It's pretty 
simple to reproduce:

Jamfile
--------
Library libtest : object.c ;


object.c
---------
void object_function () { }


Every time you run jam, the object gets rebuilt and so does
the archive. 
I've stepped through the jam code with gdb, and the problem
appears to 
be in the time stamp check. That is, object.o gets a
timestamp of 0 
(since it gets deleted after being archived) and object.c is
always 
newer. This doesn't happen on SUSE, but I'm not sure what
the difference 
is.

I don't know if it's related, but I've also noticed that jam
doesn't run 
ranlib on OSX. Is this by design or a bug?

I know it's not useful to say a problem is urgent, but I'm
facing a 
constant rebuild of every file in my project, so even a
cheap hack 
workaround would be welcome.

Thank you!

-- Sal
smile.


--------------
   Salvatore Domenick Desiano
     Doctoral Candidate
       Robotics Institute
         Carnegie Mellon University
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: Jam newer bug on OSX
country flaguser name
Russian Federation
2007-03-04 07:43:55
On Thursday 01 March 2007 05:02, Salvatore Domenick Desiano
wrote:
> I seem to have run into a bug in timestamp checking on
OSX. It's pretty 
> simple to reproduce:
> 
> Jamfile
> --------
> Library libtest : object.c ;

The 'Library' above makes me thing you're using
classic jam rules, not Boost.Build. Unfortunately,
those are completely unsupported.

> Every time you run jam, the object gets rebuilt and so
does the archive. 
> I've stepped through the jam code with gdb, and the
problem appears to 
> be in the time stamp check. That is, object.o gets a
timestamp of 0 
> (since it gets deleted after being archived) and
object.c is always 
> newer. This doesn't happen on SUSE, but I'm not sure
what the difference 
> is.

object.o should have TEMPORARY flag on it to prevent that. I
have
no idea why behaviour on SUSE and OSX is different. But
anyway,
unless you're using Boost.Build rules ("lib"),
there's nothing we can do.

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: Jam newer bug on OSX
country flaguser name
United States
2007-03-04 14:38:46
I found the problem, and I've fixed it for my install. I am
using the
old Perforce rules, but the bug turns out to be in
fileunix.c. 
ofileunix.c doesn't check to see if the library is in the
BSD extended
format. The attached patch works on OSX 10.4, and checks
defines to 
ensure that it only triggers on BSD systems, but hasn't been
tested 
anywhere else.

If I can be of any assistance in fixing or testing this
problem, just 
let me know.

-- Sal
smile.

--------------
  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University

On Sun, 4 Mar 2007, Vladimir Prus wrote:

o On Thursday 01 March 2007 05:02, Salvatore Domenick
Desiano wrote:
o > I seem to have run into a bug in timestamp checking
on OSX. It's pretty 
o > simple to reproduce:
o > 
o > Jamfile
o > --------
o > Library libtest : object.c ;
o 
o The 'Library' above makes me thing you're using
o classic jam rules, not Boost.Build. Unfortunately,
o those are completely unsupported.
o 
o > Every time you run jam, the object gets rebuilt and
so does the archive. 
o > I've stepped through the jam code with gdb, and the
problem appears to 
o > be in the time stamp check. That is, object.o gets a
timestamp of 0 
o > (since it gets deleted after being archived) and
object.c is always 
o > newer. This doesn't happen on SUSE, but I'm not sure
what the difference 
o > is.
o 
o object.o should have TEMPORARY flag on it to prevent that.
I have
o no idea why behaviour on SUSE and OSX is different. But
anyway,
o unless you're using Boost.Build rules ("lib"),
there's nothing we can do.
o 
o - Volodya
o _______________________________________________
o Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
o 
o 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

  
Re: Jam newer bug on OSX
country flaguser name
United States
2007-03-08 23:57:19
Are there additional steps I should take to have this patch
(or 
something like it) moved into the build tree?

Thank you.

-- sal
smile.




--------------
  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University

On Sun, 4 Mar 2007, Salvatore Domenick Desiano wrote:

o I found the problem, and I've fixed it for my install. I
am using the
o old Perforce rules, but the bug turns out to be in
fileunix.c. 
o ofileunix.c doesn't check to see if the library is in the
BSD extended
o format. The attached patch works on OSX 10.4, and checks
defines to 
o ensure that it only triggers on BSD systems, but hasn't
been tested 
o anywhere else.
o 
o If I can be of any assistance in fixing or testing this
problem, just 
o let me know.
o 
o -- Sal
o smile.
o 
o --------------
o   Salvatore Domenick Desiano
o     Doctoral Candidate
o       Robotics Institute
o         Carnegie Mellon University
o 
o On Sun, 4 Mar 2007, Vladimir Prus wrote:
o 
o o On Thursday 01 March 2007 05:02, Salvatore Domenick
Desiano wrote:
o o > I seem to have run into a bug in timestamp checking
on OSX. It's pretty 
o o > simple to reproduce:
o o > 
o o > Jamfile
o o > --------
o o > Library libtest : object.c ;
o o 
o o The 'Library' above makes me thing you're using
o o classic jam rules, not Boost.Build. Unfortunately,
o o those are completely unsupported.
o o 
o o > Every time you run jam, the object gets rebuilt and
so does the archive. 
o o > I've stepped through the jam code with gdb, and the
problem appears to 
o o > be in the time stamp check. That is, object.o gets
a timestamp of 0 
o o > (since it gets deleted after being archived) and
object.c is always 
o o > newer. This doesn't happen on SUSE, but I'm not
sure what the difference 
o o > is.
o o 
o o object.o should have TEMPORARY flag on it to prevent
that. I have
o o no idea why behaviour on SUSE and OSX is different. But
anyway,
o o unless you're using Boost.Build rules ("lib"),
there's nothing we can do.
o o 
o o - Volodya
o o _______________________________________________
o o Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
o o 
o o 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )