RE: [ANNOUNCEMENT] Updated: cygwin-1.3.11-3

["Harig, Mark A." <maharig at idirect dot net>]

Thank you for making it (the timing issue) public.
It helped resolve a problem I was having.

I have a process that does the following steps:

   1. generate assembly language from c code
   2. assemble the .asm into .o
   3. archive the .o into .a

With 'make' this worked well on the first pass
through these three steps, but if I invoked 'make'
immediately after the .a was generated, then 'make'
thought that the .a was out-of-date with respect to
some -- but not all -- of the .o files.

The reason?  The recorded dates for the .o's within
the .a was within the same second as the timestamp
for the .o's.  If I ran 'make' a second time, then
the timestamps of "internal" .o's was different from
the .o files.  A third invocation of 'make' found that
the .a was up to date.  But this is an error because the
.a should have been up to date after the first invocation.  

The "solution"?  I added step 1a. "sleep 1":

   1. generate assembly language from c code
   1a. sleep 1
   2. assemble the .asm into .o
   3. archive the .o into .a

I don't know if this will be a common problem or not.

Should it be considered part of the standard Cygwin build
of 'make' that the '--disable-nsec-timestamps' be used
during configuration?


> -----Original Message-----
> From: Conrad Scott [mailto:Conrad.Scott@dsl.pipex.com]
> Sent: Monday, June 24, 2002 6:29 PM
> To: Heribert Dahms; cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] Updated: cygwin-1.3.11-3
> 
> 
> "Heribert Dahms" <heribert_dahms@icon-scm.com> wrote:
> > Hi Conrad,
> >
> > wow, you seem to have a really fast machine, where
> > you can run multiple nontrivial makes per second 8-)
> 
> Not *nontrivial* perhaps . . .
> 
> It's part of a (still ongoing) attempt to write a makefile that
> handles compiling TeX files, where you've got to re-do the processing
> an arbitrary number of times until the output settles down: I've
> currently got a makefile that touches marker files depending on
> various conditions and then re-invokes itself. But some of the phases
> don't take very long to run, so sometimes things don't get re-compiled
> when they should. Actually, I should probably be more delicate than to
> discuss it in public . . . it's *really* foul. Then again, if it ever
> works, it'll all of a sudden be beautiful :-)
> 
> // Conrad
> 
> 
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/