Title: | USG buildhelp questions/answers |
Moderator: | SMURF::FILTER |
Created: | Mon Apr 26 1993 |
Last Modified: | Mon Jan 20 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 2763 |
Total number of notes: | 5802 |
Date Of Receipt: 11-APR-1996 11:21:30.99 From: SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group 11-Apr-1996 1119" To: rnf@DEC:.zko.flume, lindner@DEC:.zko.flume CC: slrundba@DEC:.zko.flume, odehelp@DEC:.zko.flume Subj: Bob or Dave, do you know the answer to this? ------- Forwarded Message Return-Path: slrundba Received: from ralpha.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA25937; Thu, 11 Apr 1996 10:23:09 -0400 Received: from bwasted.zk3.dec.com by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM) id AA28754; Thu, 11 Apr 1996 10:23:02 -0400 Received: from scarlett.zk3.dec.com by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00265; Thu, 11 Apr 1996 10:23:01 -0400 Received: from localhost by scarlett.zk3.dec.com (5.65v3.2/1.1.10.5/23Feb96-111 0AM) id AA08661; Thu, 11 Apr 1996 10:20:25 -0400 Message-Id: <[email protected]> To: odehelp Cc: slrundba Subject: I18N and Makefiles... Date: Thu, 11 Apr 96 10:20:24 -0400 From: slrundba X-Mts: smtp Hello! I'm an engineer on the LSM team. We are focusing our efforts on the next release of LSM. Included is the internationalization of our code. I'm running into a problem incorporating I18N into our Makefiles. How do the MSGHDRS and CATDEFS targets get built? If I put these rules in a Makefile that includes OFILES, it works fine. If I put them in a Makefile by themselves or in another command's Makefile that doesn't specify OFILES, it won't build. The rules are simply ignored. Why? Is that just a coincidence, and there's really another trigger? If so, what is it? When we incorporated I18N to LSM in Platinum, we put the I18N rules in a Makefile in our /common directory that happened to include OFILES. That meant that everytime an engineer made a change to the message source file, he/she had to build that directory which took a long time. It made sense to put the rules there at the time as all of our 'common' stuff is in there. The build process became so cumbersome, however, we decided to try a different approach in Steel, but now we are running into problems. I believe that Steve Corbin, another LSM engineer, already sent you guys mail regarding this problem. He never got a response, so we thought we'd try again. Any input you can provide will be appreciated. Thank you, Susan Rundbaken LSM Engineer [email protected] ------- End of Forwarded Message -- ______________________________________________________________________ John Flanagan enet: [email protected] MS: ZKO3-3/W20 decnet: flume::johnf USG Release Engineering (603) 881-1719 110 Spitbrook Road (DTN) 381-1719 Nashua, NH ______________________________________________________________________
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
2208.1 | Re: Bob or Dave, do you know the answer to this? | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri May 03 1996 16:49 | 53 |
Date Of Receipt: 11-APR-1996 14:37:32.97 From: SMURF::QUARRY::lindner "David Lindner 11-Apr-1996 1434" To: John Flanagan - UNIX Systems Group <johnf@DEC:.zko.quarry> CC: rnf@DEC:.zko.quarry, lindner@DEC:.zko.quarry, slrundba@DEC:.zko.quarry, odehelp@DEC:.zko.quarry Subj: Re: Bob or Dave, do you know the answer to this? > How do the MSGHDRS and > CATDEFS targets get built? If I put these rules in a Makefile that includes > OFILES, it works fine. If I put them in a Makefile by themselves or in another > command's Makefile that doesn't specify OFILES, it won't build. The rules are > simply ignored. Why? Is that just a coincidence, and there's really another > trigger? If so, what is it? Thats correct. PROGRAM/PROGRAMS would also trigger it, because they are part of the generic targets specified in the makefiles. You need some generic target variable in order to set all the variables in the make scripts for this to work. Perhaps there is some null command or object that you can pass as a program or an ofile that would key the build. I'm not an expert in this area, so perhaps someone else could comment. Barring that, you could create a null.c program that you specify as a target. It wouldn't do anything, except key the rest of the build procedure. > When we incorporated I18N to LSM in Platinum, we put the I18N rules in a > Makefile in our /common directory that happened to include OFILES. That meant > that everytime an engineer made a change to the message source file, he/she > had > to build that directory which took a long time. It made sense to put the rules > there at the time as all of our 'common' stuff is in there. The build process > became so cumbersome, however, we decided to try a different approach in > Steel, > but now we are running into problems. Well, I'm sorry that you find this process cumbersom, but make/build is doing what its supposed to do. Each time you change one of the message catalogs, you *should* have to rebuild the files that include the affected headers, how else are the changed headers going to be picked up? By doing this you're going to have header files and message catalogs that are out of sync with the rest of your code. Of course when you do a full build everything should be in sync, but that would be it. Its your code, so you can do what you want, but it seems like you guys are just asking for trouble. Dave |