Subject:
|
Re: pictures at tracker
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 May 2002 20:07:57 GMT
|
Viewed:
|
860 times
|
| |
| |
In lugnet.cad, Kyle McDonald writes:
> Steve Bliss wrote:
> > We've basically got one, although it might not be very efficient. Right
> > now, it spits out a file of lines like:
> >
> > <datfile> <subfile> <library>
>
> So something could be written that would convert this to Make format
> or it could read the files themselves.
Or the something that creates the file could write the Make format itself.
> Yes, because the s/ is in the datfile, and if it was kept in the
> dependency file, Make would look for s/973s01.dat in all the directories
> in the vpath, or VPATH. That will work.
OK. The current dependency file already includes the location (up to p/ or
parts/), but if that work could be pushed off on make, it might be worth it.
> I wonder if there is any need to keep both official and unofficial
> picture libraries though?
I'd rather avoid it. We've been running at 500+ unofficial files, but there
are almost 2500 official files. That's a lot of png files!
BUT, if the dependencies target the image files, how can Make track
correctly without images for the official files?
We could make dummy stubs for the official images.
Or we could leave the official files out of the dependency file(s), and do a
full make at each part release. Official files only change at part release
time; and even then, they're only getting the code that already existed in
the unofficial files, so there's really no changes needed in the unofficial
images.
> Well, if someone updates a primitive, like say 'stud.dat' this
> *will* cause Make to consider pretty much every .png file to be
> 'out of date' which will cause it to remake the .png for every
> .dat that depends on it. Actually, isn't this is the desired
> behavior?
Yes, it is the correct behavior.
> The trick is to make sure that this doesn't take CPU cycles away
> from the WebServer processes.
Yes.
> Something could be done with some
> sort of locks so ensure that 2 Makes don't get run at once.
Yes.
> Also
> it may be possible to use 'nice' or something to have make (and
> the commands it runs) run at a lower priority level.
Might be a good idea.
> Another alternative would be to run the make on a separate machine.
Blink. I suppose. Dunno if that's practical.
> Or to not run it when the files are submitted, but instead at
> certain intervals during the day.
Maybe.
> I would think that a part submission should only cause make to
> remake 1 .png. A subpart submission probably would trigger 5-30
> .png's to be remade? primitves could cause many many .png's to
> be remade.
Subparts *usually* only trigger 1 or 2 other files; some subparts trigger
dozen(s) of other files.
Primitives can trigger anything from 1 to 30+ files.
> Maybe changes from parts and sub-parts could be done at
> submission, but changes from primitives are done every 4-6 hours?
>
> Or a slightly different method would be, if 3001.dat is submitted,
> then only run 'make 3001.png' instead of 'make.' Likewise if
> stud.dat were submitted, you could only run 'make stud.png' right
> away. Then at some point (maybe midnight) cron could run 'make'
> which would update all the other files that depended on the files
> that had been submitted that day.
That sounds like it might be a plan.
Steve
|
|
Message has 1 Reply: | | RE: pictures at tracker
|
| All, I've got my Linux system runnig on the test machine, now I need to ldglite up and running. I got the mesa lib, but does anyone have a pre-built version of ldglite I can use? I'll work on things this weekend and let you know how things are (...) (23 years ago, 17-May-02, to lugnet.cad)
|
Message is in Reply To:
| | Re: pictures at tracker
|
| (...) So something could be written that would convert this to Make format or it could read the files themselves. (...) Yes, because the s/ is in the datfile, and if it was kept in the dependency file, Make would look for s/973s01.dat in all the (...) (23 years ago, 16-May-02, to lugnet.cad)
|
77 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|