Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
Re: pictures at tracker
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 May 2002 17:29:43 GMT
|
Viewed:
|
685 times
|
| |
|
|
Replying to a couple of things at once (and resisting the urge to XFUT
lugnet.cad.dev.org.ldraw, which should have happened 30 messages
ago...).
In lugnet.cad, Ralph Hempel wrote:
> I'm going to step in here and volunteer my efforts as a make expert to
> the group. I use make every day and have an extensive system that allows
> me to build embedded software for multiple platforms and hardware
> versions from one source tree,
That sounds great! That's if it's ok with Jacob.
> Here are some general thoughts....
>
> 1. You definitely need a dependency generator. This is pretty
> easy to do with sed, awk, perl, tcl - whatever. This program
> would spit out a list of heirarchical dependencies for each
> thing that it processes.
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>
> 2. The VPATH and inference rule features of GNU make are powerful
> and easy to use constructs. I use them to handle building
> complete libraries within subdirectories of the working
> code. It should be easy to adapt to the parts tracker.
Hmm. There are four directories in an ldraw library: parts, parts/s, p,
and p/48. When a dat file references a subfile in the parts/s or p/48
directories, it includes a leading s\ or 48\ on the subfile name. So
973.dat has a line like:
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\973s01.dat
If this was written in a dependency as (as Kyle suggested for the file
extensions)
973.png: 973.dat s\973s01.pic
could VPATH be used to track down 973s01.dat in
{symlib}/parts/s/973s01.dat? Otherwise, we can just create the
dependency files with full paths.
> Let me know exactly what you need and the tools (programs) you have
> access to on the target box and I'll bang together a make script
> for you.
I *think* there would be only one production: producing a PNG file out
of a dat, using ldglite. The exact commandline is depending on any
changes Don makes to ldglite to support this effort.
> If it's not clear, i LOVE make. I use it for all kinds of tasks,
> including building pbForth from scratch and then building zip
> archives and sending them to the server.
:)
> I hope I can help in some small way...
I think you can. :)
Farther up the thread, but later in time, Ralph Hempel wrote:
> So, I need a couple of things to get going on this:
>
> 1. A brief description of the box this will run on, including common
> programs we have access to(perl, awk, sed) and a list of programs
> we don't have access to.
Uh, it's about 55cm x 25cm x ...
Seriously, it's a linux box with most standard programs. I can't really
tell you what we don't have access to -- I have no idea what you'd
expect to have access to. Heck, I'm still coming to greps with what we
do have. Jacob would be the best source for info about the server.
> 2. A brief description of the current part directory scheme and how
> unofficial parts and official parts must coexist peacefully. If possible,
For our purposes, unofficial parts are newer revisions of official
parts. Basically, there are two trees, as I outlined in an earlier
message. But, if we build a directory of symlinks, then we just have
the standard LDraw library structure.
> I neeed info on breakage scenarios. I just started using MLCad recently
> and I understand that uing an unofficial 24T gear may break my models
> after an official release. I'm unsure why....
Unofficial versions are sometimes incompatible with the official
versions because we might reposition the part, or some geometry in the
part might be adjusted.
> 3. Brief spec for the workflow. Something like this:
You've got it basically right.
> I'm assuming that if I get the complete parts catalog and the updates and
> expand them in an "official" tree, then get all of the unofficial parts
> and expeand them in an "unofficail" tree, I could build a "release" tree
> using nothing but symlinks.
Yes, that's correct. Although I'm going to guess that we won't be
totally rebuilding the symlibrary every 2 minutes (which is how often
new submissions are processed into the tracker).
Steve
|
|
Message has 2 Replies:
 | | Re: pictures at tracker
|
| (...) not*"building*, no... but *make*-ing is quite feasible since it would be incremental and unless the upload was a major major basic primitive, not of huge effect, right? I am thinking that you run make as a background job from cron every 2 min (...) (22 years ago, 16-May-02, to lugnet.cad)
| | | 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 (...) (22 years ago, 16-May-02, to lugnet.cad)
|
Message is in Reply To:
| | RE: pictures at tracker
|
| (...) I'm going to step in here and volunteer my efforts as a make expert to the group. I use make every day and have an extensive system that allows me to build embedded software for multiple platforms and hardware versions from one source tree, (...) (22 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
|
|
|
|
