Can @file have multiple lines? I suspect it doesn't have to be a single
line with multiple filenames... that is the way most response files are
set up. If so...

dummyfile : *.java
     sh echo $? | xargs -n 10 echo >> file
     javac @file
     touch dummyfile

with some preliminary rule that rm's file. That will create file with a
maximum of 10 filenames per line.

The leading sh also isolates the command environment from make, which
starts out by filling the environment with everything make.

If that doesn't work, you can run a ls into a output file and then use
sed or something to reformulate it into what is needed. That would require
a preliminary rule to create the file and a second rule to run javac.

good luck! john

On Fri, 17 Mar 2000, Mohan Krishnan wrote:

> Hi John:
> 
> I saw the xargs solution in the cygwin news group. but does it  work from
> within the make utility?
> e.g. for the following rule
> 
> dummyfile : *.java
>     echo $? > file
>     javac @file
>     touch dummyfile
> 
> 
> When make launches a shell  to execute the echo command. the $? expands to a
> very large list and fails. so even if I have xargs in there, the $? is still
> gonna expand and cause make or sh to crash.
> is there a specific way that i can use a combination of $? and xargs ?
> 
> Thanks,
> Mohan
> 
> 
> ----- Original Message -----
> From: "John Alvord" <[EMAIL PROTECTED]>
> To: "Mohan Krishnan" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Friday, March 17, 2000 2:14 PM
> Subject: Re: Timestamp is not being checked on NT + other
> 
> 
> > I have solved similar problems using xargs to break up the long list of
> > names into manageable chunks. This is on a NT system. john
> >
> > On Fri, 17 Mar 2000, Mohan Krishnan wrote:
> >
> > > Hi Paul:
> > >     I am faced with another problem regarding the command line length. I
> > > have a large dependency list which I am echoing to a file using
> > >
> > > echo $? > some_file
> > >
> > > And on NT sh.exe (from cygnus) keeps crashing saying either command like
> too
> > > long or STATUS_ACCESS_VIOLATION.
> > >
> > > Is there a cure for this?
> > >
> > > Really appreciate your time,
> > > rgds
> > > mohan
> > >
> > > ----- Original Message -----
> > > From: "Paul D. Smith" <[EMAIL PROTECTED]>
> > > To: "Mohan Krishnan" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Thursday, March 16, 2000 6:59 AM
> > > Subject: Re: Timestamp is not being checked on NT + other
> > >
> > >
> > > > %% "Mohan Krishnan" <[EMAIL PROTECTED]> writes:
> > > >
> > > > Hi; please don't send HTML to the list, thanks!
> > > >
> > > >   mk> I hv make version 3.78.1 on NT.
> > > >
> > > >   mk> 1) make reports "nothing to make" even though the target has
> > > >   mk> changed. Same test works fine on Solaris.  I am attaching a
> small
> > > >   mk> test Makefile with some test files.  First time through make
> will
> > > >   mk> create the .out files (by touch.exe). Now open up aaa.txt and
> edit
> > > >   mk> and save it. then try make again. It would report nothing to
> make.
> > > >
> > > > I can't reproduce this on UNIX and I don't have any Windows systems.
> I
> > > > don't really support the Windows port; you need to talk to the folks
> > > > that do (see the AUTHORS file in the GNU make distribution).
> > > >
> > > > However, I do know that due to limitations in the Windows filesystem,
> > > > GNU make is forced to treat all timestamps within 2 or 3 seconds of
> each
> > > > other as identical.  So, if you update that file sufficiently quickly
> > > > from the time the .out file was changed make might not notice there's
> > > > been a change.
> > > >
> > > > Comments in the code say:
> > > >
> > > >   #ifdef WINDOWS32
> > > >           /*
> > > >            * FAT filesystems round time to nearest even second(!).
> Just
> > > >            * allow for any file (NTFS or FAT) to perhaps suffer from
> this
> > > >            * braindamage.
> > > >            */
> > > >           if (mtime > now && (((mtime % 2) == 0) && ((mtime-1) >
> now)))
> > > >   #else
> > > >   #ifdef __MSDOS__
> > > >           /* Scrupulous testing indicates that some Windows
> > > >              filesystems can set file times up to 3 sec into the
> future!
> > > */
> > > >           if (mtime > now + 3)
> > > >   #else
> > > >           if (mtime > now)
> > > >   #endif
> > > >   #endif
> > > >
> > > > Other than that, I'm afraid I don't have much to say.  Try running
> make
> > > > with the -d option and see why it doesn't want to remake the file.
> > > >
> > > >   mk> 2) This problem occurs both in NT and Solaris. If the target is
> a
> > > >   mk> directory in your present working directory then make will
> always
> > > >   mk> report "xyz is up to date"!
> > > >
> > > > This isn't a bug, this is expected behavior.  Make doesn't
> differentiate
> > > > between directories and files: if the target exists, it exists.
> > > >
> > > > What if you _wanted_ to write a target that created a directory:
> > > >
> > > >   $(OBJDIR): ; mkdir $(OBJDIR)
> > > >
> > > > ?  This is actually not that uncommon (although not the best way to do
> > > > it, IMO).
> > > >
> > > > Look up the .PHONY rule in the GNU make manual for how to make this
> work
> > > > as you want.
> > > >
> > > > --
> > >
> > --------------------------------------------------------------------------
> > > -----
> > > >  Paul D. Smith <[EMAIL PROTECTED]>         Network Management
> > > Development
> > > >  "Please remain calm...I may be mad, but I am a professional." --Mad
> > > Scientist
> > >
> > --------------------------------------------------------------------------
> > > -----
> > > >    These are my opinions---Nortel Networks takes no responsibility for
> > > them.
> > > >
> > >
> >
> 

Reply via email to