X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com From: John Doty Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-116--106531282 Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting a gEDA project Date: Tue, 15 Jan 2013 20:01:14 -0700 In-Reply-To: To: geda-user AT delorie DOT com References: <87wqvhd4tw DOT fsf AT gmail DOT com> <20130115013756 DOT 9917 DOT qmail AT stuge DOT se> <50F4E4D1 DOT 3010802 AT ecosensory DOT com> <878v7uv4gl DOT fsf AT gmail DOT com> Message-Id: X-Mailer: Apple Mail (2.1085) Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --Apple-Mail-116--106531282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 15, 2013, at 11:51 AM, Ouabache Designworks wrote: >=20 > Version control systems were designed by software engineers for = software engineers. A lot of hardware design now > resembles software programming so we can use a lot of their tools BUT = not all of them. Hardware design is more complex than > software programming and not all software tools will work. Version = control is one of them. Hardware design is certainly not more complicated than software in my = experience. >=20 > A programmer knows that all .log and .obj files are generated so it = is easy to set up git to ignore all of them. Cleaning them > out between runs is a simple wild card operation. >=20 > The hardware designer does not know if a verilog .v file was = handcrafted and must be checked in or generated by finiteStateMachine > tool and should not be checked in. Setting up the ignore and clean = functions can be done but will take a lot of effort. Using something > like lndir saves a lot of effort in the long run and doesn't break = down in the middle of a design project. But this happens frequently in software. Programs often generate = programs. You may start with Makefile.am, generate Makefile.in, then = Makefile, then compile link and run a project specific tool that = generates C source code, compile and link that, etc. generating lots of = derived "source" files. Very common in software, but I've never seen a = hardware development flow so complicated. >=20 > The thing to remember about VersionControl is that your design data is = probably going to live on long after the VersionControlSystem du_jour = has > been dumped for the next best one. When selecting a new one the only = thing you need to know is how to get your data and checkin logs out of > it when it comes time to move on to a newer VCS. Well, in the free/open world things tend to stick around. My RCS = archives from the 1980's are still perfectly usable. You can even obtain = a rewrite of SCCS, from the 1970's, if you wish. In hardware, it's the other things that move faster. I still have = hardware designs from 20 years ago on my computer, but I don't have the = EDA system that I used. In any case, I'd have to rob a museum to get the = parts ;-) Many of my projects are mixtures of hardware and software. It's very = nice to have both under a common VCS, especially when the software = depends on which version of the hardware I'm building for. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail-116--106531282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Version control systems were designed by software = engineers for software engineers. A lot of hardware design = now
resembles software programming so we can use a lot of their tools = BUT not all of them. Hardware design is more complex than
software programming and not all software tools will work. Version = control is one of them.

Hardware design = is certainly not more complicated than software in my = experience.

A programmer = knows that all .log and .obj files are generated so it is easy to = set up git to ignore all of them. Cleaning them
out between runs is a simple wild card operation.

The hardware = designer does not know if a verilog .v file was handcrafted and must be = checked in or generated by finiteStateMachine
tool and should not be = checked in. Setting up the ignore and clean functions can be = done but will take a lot of effort. Using something
like lndir saves a lot of effort in the long run and doesn't break down = in the middle of a design project.

But = this happens frequently in software. Programs often generate programs. = You may start with Makefile.am, generate Makefile.in, then Makefile, = then compile link and run a project specific tool that generates C = source code, compile and link that, etc. generating lots of derived = "source" files. Very common in software, but I've never seen a hardware = development flow so complicated.

The thing to remember about VersionControl is that = your design data is probably going to live on long after the = VersionControlSystem du_jour has
been dumped for the next best one. When selecting a new one the = only thing you need to know is how to get your data and checkin logs out = of
it when it comes time to move on to a newer = VCS.

Well, in the free/open world things = tend to stick around. My RCS archives from the 1980's are still = perfectly usable. You can even obtain a rewrite of SCCS, from the = 1970's, if you wish.

In hardware, it's the = other things that move faster. I still have hardware designs from 20 = years ago on my computer, but I don't have the EDA system that I used. = In any case, I'd have to rob a museum to get the parts = ;-)

Many of my projects are mixtures of = hardware and software. It's very nice to have both under a common VCS, = especially when the software depends on which version of the hardware = I'm building for.

John Doty Noqsi = Aerospace, Ltd.

http://www.noqsi.com/

jpd AT noqsi DOT com

= --Apple-Mail-116--106531282--