[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

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

2206.0. "I18N and Makefiles..." by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Fri May 03 1996 16:37

Date Of Receipt: 	11-APR-1996 10:25:22.27
From: 	SMURF::WASTED::slrundba "Susan Rundbaken USG  11-Apr-1996 1020"
To: 	odehelp@DEC:.zko.wasted
CC: 	slrundba@DEC:.zko.wasted
Subj: 	I18N and Makefiles...

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]

T.RTitleUserPersonal
Name
DateLines
2206.1I18N and Makefiles...AOSG::FILTERAutomatic Posting Software - mail to flume::puckFri May 03 1996 16:3862
Date Of Receipt: 	11-APR-1996 10:30:16.66
From: 	SMURF::FLUME::slrundba "Susan Rundbaken USG  11-Apr-1996 1024"
To: 	[email protected]
CC: 	slrundba@DEC:.zko.flume
Subj: 	I18N and Makefiles...

Hello! I sent this message to odehelp and got a response indicating that all 
build issues should be sent to you...


------- Forwarded Message

Return-Path: slrundba
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-1110AM)
	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