headers
Jeremy Cowgar | 1 May 2009 23:32
Favicon
Gravatar

Setting CCFLAGS for a library

I have to set CCFLAGS to contain /dERUNTIME only when building a 
specific library. For the rest of the time, /dERUNTIME should not be 
part of the CCFLAGS variable. I tried this:

Library runtime : file1.c ;
CCFLAGS on runtime = /dERUNTIME $(CCFLAGS) ;

and that did not work. The only way I could get file1.c to compile with 
/dERUNTIME was:

CCFLAGS on file1.obj = /dERUNTIME $(CCFLAGS) ;

That is both cumbersome and problemsome for me because I use file1.c 
else where and if ERUNTIME is defined then file1 contains code that will 
cause problems.

So my question is, how can I set the CCFLAGS for all files within a 
library but not cause all instances of that file to contain those flags?

Thanks,

Jeremy
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
Permalink | Reply | 0 comments |
headers
Jeremy Cowgar | 2 May 2009 00:06
Favicon
Gravatar

Re: MakeLocate

Craig Allsop wrote:
> Hi Jeremy,
>
> Just out of interest I put all our executables/dlls in
> '$(TOP)/bin/...' because we have this in our path and all our objs
> into '$(TOP)/obj/libraryname/configurationname/...' but that's me, how
> would *you* like it to work?
>   

Craig,

That sounds good. Do you have an example somewhere as to how I can 
accomplish this?

Jeremy
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
Permalink | Reply | 1 comment |
headers
Jeremy Cowgar | 2 May 2009 00:23
Favicon
Gravatar

Re: MakeLocate

Jeremy Cowgar wrote:
> Craig Allsop wrote:
>   
>> Hi Jeremy,
>>
>> Just out of interest I put all our executables/dlls in
>> '$(TOP)/bin/...' because we have this in our path and all our objs
>> into '$(TOP)/obj/libraryname/configurationname/...' but that's me, how
>> would *you* like it to work?
>>   
>>     
>
> Craig,
>
> That sounds good. Do you have an example somewhere as to how I can 
> accomplish this?
>   

Hm, I figured this out (from a previous email) the only problem I have 
is setting the output properties on the same file for different values 
when compiled as part of a different project. This ties into my other 
question I recently sent to the list, i.e. setting CCFLAGS for a given 
file when part of a project. Here is an example:

Library runtime : be_machine.c be_runtime.c ;
Library user : be_machine.c be_pcre.c ;

So, be_machine.c is shared between the runtime library and the user 
library. I find that if I do a MakeLocate on be_machine.obj, then for 
both the runtime and user compilations, it is written to the same
(Continue reading)

Permalink | Reply | 0 comments |
headers
Craig Allsop | 12 May 2009 01:26
Picon

Re: Generation of C source w/unknown resulting names?

Hi John,

On Sat, May 9, 2009 at 3:55 AM, John Waugh <john.waugh <at> gmail.com> wrote:
> (Sorry if this is a duplicate - I was getting groans from the mail
> system so sent again just in case)
>
> On Mon, Apr 20, 2009 at 9:24 PM, Craig Allsop <cjamallsop <at> gmail.com> wrote:
>> Hi Jeremy/guys,
>>
>> Personally I think a modified jam that simply exposes the HdrRule
>> function as a built-in function that can be called to scan
>> dependencies during rule phase which would best solve your problem
>> allowing you to run in only one invocation.
>
> Dredging up an old thread - I don't think I understand what you mean
> here, and was wondering if you could enlighten me.
> I'm also trying to figure the best way to get generated files picked
> up by Jam (preferably in a single pass).
>
> How does doing HdrRule-style scanning during *rule* phase help?
> If the generated files don't get created until after actions are run,
> then the files simply won't exist during rule phase - how would
> HdrRule help here?

So it looks simple enough right, .e builds to .c builds to .obj links
to .exe and we (Jeremy) would like to write:

Main exe : something.e ;

Ideal dependencies are:
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Waugh | 14 May 2009 00:27
Picon

Re: Generation of C source w/unknown resulting names?

On Mon, May 11, 2009 at 4:26 PM, Craig Allsop <cjamallsop <at> gmail.com> wrote:
> So it looks simple enough right, .e builds to .c builds to .obj links
> to .exe and we (Jeremy) would like to write:
>
> Main exe : something.e ;
>
> Ideal dependencies are:
>
> 1. exe -> something.obj -> something.c -> something.e -> console.e -> get.e
> 2. exe -> console.obj -> console.c -> console.e
> 3. exe -> get.obj -> get.c -> get.e
>
> The problem is, during rule phase, all we can determine is the
> dependencies labeled 1. The HdrRule attached to something.e will find
> console.e & get.e but since this rule runs during the phase where jam
> determines the fate of something.obj we aren't allowed (by design, see
> Jambase) to attach more dependencies to higher level targets, such as
> exe however, at this point we discover the exe should also now depend
> on console.obj and get.obj, i.e. dependencies labeled 2 & 3.

Ah, I think I understand. I somehow had it in my head that we were
talking about "one to many" generation of files - trying to set up
dependencies for generated files where there might be an indeterminate
number of generated files based on one source file.

> The solution to this is to scan .e files completely during rule phase
> because in this phase we can attach dependencies to higher level/any
> targets and by the time jam gets to the next phase it will know the
> whole picture, thus allowing you to complete a one pass build of this
> kind of scenario. (hope I explained it clearly enough)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Petersen | 14 May 2009 08:55

Out-of-source build

Hello,

I try to set up an out-of-source build environment with some CORBA sources 
compiled by the omniIDL compiler. We are generating the implementation using 
the *SK.cpp and *.hh possibility of the idl-compiler. That means that the 
interfaceA.idl file is compiled into an interfaceASK.cpp and an interfaceA.hh 
file. Those file are located out of the source-directories as well as the 
binary files. 

~/build |
	+gen -
	|    *.hh
	|    *SK.cpp
	|
	+bin |
	     +Debug -
	     |             +app1 -
	     |              |      app1.o
	     |              |      app1
 	     |  	           +app2 -
	     |		    |	  app2.o
	     |		    |	  app2
	     |		    +lib1 -
	     |		    |	  lib1.o
             |		    |	  lib1.a
	     |		    +lib2 -
	     |		    |	  lib1.o
	     |		    |	  lib1.a
	     |              +idl -
	     |                   *SK.o
(Continue reading)

Permalink | Reply | 2 comments |
headers
Craig Allsop | 14 May 2009 09:27
Picon

Re: Out-of-source build

Hi.

1. Yes.
2. Not necessary.
3. See 2.
4. Not idl, however this is similar to other build patterns.

It sounds like you're on the right track to me with UserObject, use
custom rule/action to convert .idl to .cpp and pass the idl to Main.
What does your idl userobject/idl rule/idl action look like and what
part are you stuck on?

Craig.

On Thu, May 14, 2009 at 4:55 PM, Stefan Petersen
<petersen <at> alsteraero.com> wrote:
> Hello,
>
> I try to set up an out-of-source build environment with some CORBA sources
> compiled by the omniIDL compiler. We are generating the implementation using
> the *SK.cpp and *.hh possibility of the idl-compiler. That means that the
> interfaceA.idl file is compiled into an interfaceASK.cpp and an interfaceA.hh
> file. Those file are located out of the source-directories as well as the
> binary files.
>
> ~/build |
>        +gen -
>        |    *.hh
>        |    *SK.cpp
>        |
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Petersen | 14 May 2009 09:58

Re: Out-of-source build

Hi Craig,

thanks for your quick reply. In one mailing-list I found an idl-rule, that I 
have slightly modified. With the corresponding flags the idl-compiler is 
creating the files in the gen-directory. What I' m missing is the possibilty 
to compile the generated ~/build/gen/idlASK.cpp into 
~/build/bin/Debug/testlib/idlASK.o. In the rule UserObject I also do not 
understand, why the C++ rule is located before the idl rule. The rule is 
copied from this location:

http://osdir.com/ml/tools.jam/2000-06/msg00005.html

Jamfile:

SubDir TOP testlib ;

LOCATE_TARGET = $(BINDIR)/testlib ;
Library testlib : classA.cpp idlA.idl ;

Jamrules looks like:

BINDIR =  $(HOME)/build/bin/$(CONF) ;
GENDIR = $(HOME)/build/gen ;

IDLFLAGS 
= -bcxx -Wba -Wbuse_quotes -Wbkeep_inc_path  -Wbs=SK.cpp -Wbtp -Wbd=SK.cpp -I.. ;
IDL = omniidl ;

rule UserObject
{
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Petersen | 20 May 2009 08:51

Re: Out-of-source build

Hi,

>
> The end result of this example is that we can now say something like this
> in our Jamfiles:
>
> StaticLibrary libMyLibrary : FooService.idl ;
>
> The good side of this solution is that almost any code generator will fit
> this model and will take only writing a single rule/action for the
> particular generator plus adding the lines in the MakObjList and MapSrc
> rules that handle the particular file name extension.
>
> Hope this helps.
>

how could I put other cpp files to the library?

Probably like this ?

StaticLibrary libMyLibrary : FooService.idl FooServiceImpl.cpp ;

Stefan
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
Permalink | Reply | 3 comments |
headers
Craig Allsop | 20 May 2009 09:36
Picon

Re: Out-of-source build

On Wed, May 20, 2009 at 4:51 PM, Stefan Petersen
<petersen <at> alsteraero.com> wrote:
> how could I put other cpp files to the library?
>
> Probably like this ?
>
> StaticLibrary libMyLibrary : FooService.idl FooServiceImpl.cpp ;

Yes

Craig.
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
Permalink | Reply | 0 comments |

Gmane