Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!dmc From: dmc@sei.cmu.edu (Dawn Cappelli) Newsgroups: comp.databases Subject: Re: INGRES ABF & multi-architectures. Message-ID: <5205@fy.sei.cmu.edu> Date: 5 Dec 89 14:11:24 GMT References: Reply-To: dmc@sei.cmu.edu (Dawn Cappelli) Organization: Software Eng. Inst.;Carnegie-Mellon U.; Pittsburgh, PA 15213 _USA_ Lines: 48 In article gnb@bby.oz (Gregory N. Bond) writes: >We run INGRES 5.1 on Sun3 and Sun4 gear, and use ABF to develop >applications. We just got our first Sun4, and are looking for a way >to manage the dual architecture ABF binaries. It seems there is no >way to use abf on the one databse on the one application to build >binaries for multiple architectures. We have the same situation running Sun3's and Ultrix. We've solved the problem, however, in the following manner, which works just fine: First of all, always use the same source code directory and the same database. We never use the default ING_ABFDIR (~ingres/abf), which is where INGRES stores object code. We create a directory underneath the home directory of the DBA of the database called ingres/abf-os. For example, we have two ABF object code directories: ~dba/ingres/abf-sun and ~dba/ingres/abf-ultrix. The protections on those directories are: ~dba/ingres : 777 ~dba/ingres/abf* : 775 In the .cshrc file we determine the type of machine being run on currently (we have a utility which returns 'sun3' or 'vax'). We setenv ING_ABFDIR to the apropriate abf directory described above. Now, as far as the details of running under both operating systems, we try to do most development under one to minimize the confusion, then build the other when the system is ready for testing. However, we still have to go through several iterations as testing progresses. You have to get into Vifred for each form, and save the form. When the form is saved from within ABF it is compiled, which is why it must be saved under each operating system. When you select GO to run the application (or Image) it automatically recompiles anything which has been changed. Since you are using only one source code directory, it detects *all* changes made. And that's about it! It all works very well here. We end up building two images: one per operating system. When a person runs the application, we: check their terminal type & set TERM_INGRES for them, map their keys appropriately for that terminal type (since we don't use default key mappings), set their path for them, check the OS and run the appropriate image. If you have problems, send me email. -- Dawn Cappelli dmc@sei.cmu.edu sei!dmc (412) 268-6170 This is my opinion, and doesn't necessarily reflect the opinion of the SEI.