Re: [jamboost] The FOP tool (Was: [Boost-build] CVS: boost/tools/build/v2/tools fop.jam,1.1,1.2)

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2004-11-01 07:08:34

Vladimir Prus writes:
> 
> On Sunday 31 October 2004 11:00, Aleksey Gurtovoy wrote:
> 
> > - fop $(target) : $(source) ;
> > + if [ os.on-windows ]
> > + {
> > + fop-nt $(target) : $(source) ;
> > + }
> > + else
> > + {
> > + fop $(target) : $(source) ;
> > + }
> > +}
> > +
> > +actions fop-nt
> > +{
> > + set JAVA_HOME=$(JAVA_HOME)
> > + $(FOP_DIR)/fop.bat $(>) $(<)
> > }
> >
> > actions fop
> > {
> > JAVA_HOME=$(JAVA_HOME) $(FOP_DIR)/fop.sh $(>) $(<)
> > -}
> > \ No newline at end of file
> > +}
> 
> I don't think that's 100% right change. For setting variables in a 
> platform-independent way we have "common.variable-setting-command', so the 
> above would have to be:
> 
> rule fop-to-print 
> {
> ........
> PATH_SETUP on $(target) = 
> [ common.variable-setting-command JAVA_HOME : $(JAVA_HOME) ] 
> }
> 
> actions fop
> {
> $(PATH_SETUP)
> ......
> }

Feel free to adjust this as you deem appropriate. FWIW, you still have to invoke 
either 'fop.bat' or 'fop.sh' depending on the platform.

> 
> Another issue is that fop.jam requires user to specify path to FOP, while all 
> the compilers require full path to executable. If we used the same syntax for 
> fop, there would be no reason to decide if "fop.bat" or "fop.sh" should be 
> used.

Right.

> 
> Doug, what would you say if I change fop.jam to accept the fop *command*, not 
> path? There's no need to push this into this release, though.

Yes, not on the branch please.

--
Aleksey Gurtovoy
MetaCommunications Engineering