Subject:
|
RE: pictures at tracker
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 May 2002 15:42:06 GMT
|
Reply-To:
|
<rhempel@^StopSpam^bmts.com>
|
Viewed:
|
760 times
|
| |
|
|
Larry Wrote:
> Remember that make doesn't actually make things. Or find things. It just
> uses other programs to make them or find them based on production rules. In
> this case it's actually LDGlite that needs to find the correct stud.dat
> "thing", right? So IT needs to know to check in multiple places (which no
> tool currently does, they all expect to find things in certain places, right?)
This is the key point - if ldglite needs to have things in certain places
in order to work correctly, the output of our make sessions needs to set up
that structure correctly.
> But in the past, IIRC from my olden days, when we were using a tool that did
> not understand include file path checking, we would use make to create an
> *image* of the directories (by creating symbolic links not by copying the
> actual files) that we wanted with the correct (as in, newest or most
> correct) files "extracted" (symlinked, really) to the image. Or at least I
> think we did.
Yes, symlinks are super-powerful (and potentially confusing). If we're running
on a Linux box, we should take advantage of them rather than bludgeoning
ldglite to work a different way.
> What platform is the box? Linux? If so you may be all set because Linux
> supports symlinks and has a pretty powerful make, I thought (doesn't it use
> gnumake???) It also has SCCS, right? Or at least RCS? Those may help too.
Using RCS or SCCS might be a bit too much overhead, but make does know how
to retireve things from both RCS and SCCS archives, and this sure as heck
beats saving zip images of approved parts. In other words, using RCS and
SCCS gives us the advantage of having a complete history (evolution) of
a part in one place! Maybe we'll do this later.
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.
2. A brief description of the current part directory scheme and how
unofficial parts and official parts must coexist peacefully. If possible,
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....
3. Brief spec for the workflow. Something like this:
- part gets submitted for review in unoffical list
- run make to update system and generate image if necessary
- add part info to unofficial tree
- add symlink from release tree to unofficial tree
- part gets voted on and becomes official
- run make to update system and generate image if necessary
- add part info to official tree
- remove part form unofficial tree
- move symlink to release tree to official tree
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.
Hope this helps, let's keep the ideas flowing...
Cheers, Ralph
|
|
Message is in Reply To:
 | | Re: pictures at tracker
|
| (...) Well, not sure. Bear with. Remember that make doesn't actually make things. Or find things. It just uses other programs to make them or find them based on production rules. In this case it's actually LDGlite that needs to find the correct (...) (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
|
|
|
|
