RE: CORBA IDL rule

Thanks Diane,

Adding that extra DEPENDS works magic!

Cheers,
David.

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 6/13/00, 12:26:02 PM, Diane Holt <holtdl <at> yahoo.com> wrote regarding RE: 
[jamming] CORBA IDL rule:

> You might try adding the "files" pseudo-target as a dependency on your 
Idl
> targets, since "files" gets built before "lib" and "exe" do:

> rule Idl
> {
> [...]
>     DEPENDS files : $(<) $(h) ;
>     DEPENDS $(<) $(h) : $(>) ;
> [...]
> }

> I don't have any IDL stuff, so I don't have any way of testing it to make
> sure it'll do what you need, but it seems like it should.

> Diane

> --- "David Moore" <david.moore <at> dialogic.com> wrote:
> >Hi,
> >I'm trying to define a rule for CORBA IDL which will allow us to
> >build an executable by specifying the IDL files.
> >e.g.  Main server : server.cc
> >                    pet.idl
> >                    petimpl.cc
> >                    owner.idl
> >                    ownerimpl.cc
> >                    ;
> >
> >My problem is the header file generated from one .idl file may depend
> >on that generated by another .idl file.
> >e.g. owner.idl #includes pet.idl, so when owner.h is generated it
> >     has a #include "pet.h", but Jam tries to build owner.o from
> >     owner.cc and owner.h before it has run the IDL rule for pet.h
> >     and of course fails.
> >
> >This is what I have...
> >rule UserObject
> >{
> >   switch $(>:S)
> >   {
> >      case .idl : C++ $(<) : $(<:S=.cc) ;
> >                  Idl $(<:S=.cc) : $(>) ;
> >      case *    : EXIT "Unknown suffix on" $(>) "- see UserObject rule in

> >Jamfile(5)." ;
> >   }
> >}
> >
> >rule Idl
> >{
> >   # based on the Yacc rule
> >   local h ;
> >   h = $(<:BS=.h) ;
> >
> >   MakeLocate $(<) $(h) : $(LOCATE_SOURCE) ;
> >
> >   # Some places don't have an Idl.
> >   if $(IDL)
> >   {
> >      DEPENDS $(<) $(h) : $(>) ;
> >      Idl1 $(<) $(h) : $(>) ;
> >      Clean clean : $(<) $(h) ;
> >   }
> >
> >   INCLUDES $(<) : $(h) ;
> >}
> >
> >   actions Idl1
> >   {
> >      $(IDL) $(IDLFLAGS) $(>)
> >   }
> >
> >
> >I have seen Jam used in two steps:
> >- first to generate all the IDL files into C++ source regardless of
> >  if they have changed or are even used
> >- then, to compile those source files into executables as specified
> >  in a Jamfile.
> >I think Jam should be able to do better than that though, I want
> >it to manage the dependencies on the IDL files themselves.
> >
> >Thanks for any advice.
> >
> >Cheers,
> >David.
> >

> =====
> (holtdl <at> yahoo.com)

> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos -- now, 100 FREE prints!
> http://photos.yahoo.com
> _______________________________________________
> jamming mailing list  -  jamming <at> perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming

Received: from mail.nanaon-sha.co.jp (mail.nanaon-sha.co.jp [210.226.101.4])
	by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id VAA76682
	for <jamming <at> perforce.com>; Tue, 27 Jun 2000 21:43:34 -0700 (PDT)
Received: from johndell ([192.168.2.132]) by mail.nanaon-sha.co.jp
          (Post.Office MTA v3.5.3J release 223-101-J
          ID# 1001-63981U100L2S100V35J) with SMTP id jp
          for <jamming <at> perforce.com>; Wed, 28 Jun 2000 14:14:11 +0900
Message-ID: <000901bfe0bf$76fc3a00$8402a8c0 <at> johndell>
From: john <at> nanaon-sha.co.jp (John Belmonte)
To: <jamming <at> perforce.com>
Date: Wed, 28 Jun 2000 14:12:32 +0900
Organization: NanaOn-Sha Co Ltd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: [jamming] Library rule quirks with LOCATE
Sender: jamming-admin <at> perforce.com
Errors-To: jamming-admin <at> perforce.com
X-BeenThere: jamming <at> perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss the build tool Jam/MR with other users <jamming.perforce.com>

Has anyone run in to the following?  A known bug?  I'm running on linux with
recent binutils.

When LOCATE is set on a library target (or MakeLocate rule used), strange
things start happening:

    * The target is always remade even when it's current. Setting NOARSCAN
option flag seems to fix this (at a performance cost).

    * If the KEEPOBJS option flag is set, the library won't be created.

--John Belmonte