Re: Compiling the same file with different flags for different targets

Nice work.

Small mistake here, you don't want CCFLAGS on LINKFLAGS:

LINKFLAGS on $(_t) = $(CCFLAGS) -shared ;

My view on all this is that you didn't need to duplicate the source,
another way to skin the cat is to wrap them and use the power of
'local' to push your changes....

rule SharedLibrary
{
  local SUFOBJ = .slo ;
  SharedLibraryFromObjects $(<) : $(>:S=$(SUFOBJ)) ;
  Objects $(>) ;
}

rule SharedLibraryFromObjects
{
  local SUFEXE = .so ;
  MainFromObjects $(<) : $(>) ;
  LINKFLAGS on $(_t) += -shared ;
}

rule SharedObjects
{
  local SUFOBJ = .slo ;
  Objects $(<) ;
  SharedObjectCcFlags $(<) : -fPIC -fvisibility=hidden ;
}

Then once you get your head around that, you can push a whole stack of
variables in one statement with jam's built in 'on' syntax. i.e. you
setup everything beforehand like:

SUFOBJ on shared = .slo ;
SUFEXE on shared = .so ;
CCFLAGS on shared =  -fPIC -fvisibility=hidden ;

Then when you need these just call the 'on' command...

rule SharedObjects
{
   on shared
   {
      # in this scope everything set on shared-config is imported
      Objects $(<) ;

      # this is now done by the original Objects so don't need it...
      #ObjectCcFlags $(<) : -fPIC -fvisibility=hidden ;
   }

   # here everything is back to the way it was
}

So now you've seen what you can do above, you don't need to make any
Shared* rules at all. So instead of...

Main test1 : test1.c lib.c ;
SharedObjectCcFlags lib.c : -DIS_LIB ;
SharedLibrary libtest : test1.c lib.c ;
InstallSharedLibrary /some_place_safe/lib : libtest ;

... after the 3 setup definitions above just use the same normal rules
and your jamfile becomes...

Main test1 : test1.c lib.c ;

on shared
{
  ObjectCcFlags lib.c : -DIS_LIB ;
  Main libtest : test1.c lib.c ;
  InstallBin /some_place_safe/lib : libtest ;
}

Now think about this...

types = static shared ;
flavour = release debug ;

for config in $(types)!$(flavour)
{
  on $(config)
  {
    Main libtest : test1.c lib.c ;
  }
}

Or make a rule to encapsulate the loop....

rule On configs
{
  local config ;
  for config in $(configs)
  {
    on $(config) $(>[1]) $(>[2-]) : $(3) ;
  }
}

Now your jamfile might look like this...

allcfgs = $(types)!$(flavour) ; # put in jamrules

On $(allcfgs) Main test : test1.c lib.c ;
On shared!$(flavour) ObjectCcFlags lib.c : -DIS_LIB ;
On $(types)!debug ObjectCcFlags lib.c : -D_DEBUG ;
On $(types)!release ObjectCcFlags lib.c : -DNDEBUG ;

Our version of On uses a friendly syntax with slashes for example:

"pc/xb release/debug" would expand to: pc!release pc!debug xb!release xb!debug

If you want different suffix on your outputs, replace just
FAppendSuffix, e.g. it might add _xr for xbox release or _pd for pc
debug, etc. again based on some variable you set for that
configuration combination.

I could go on but where shall I stop? The point is that the standard
set of rules are quite capable of doing much more than I think people
perceive them to.

Craig.

On Thu, Dec 11, 2008 at 3:44 AM, Mihai Christodorescu
<announcements.for.warkdarrior <at> gmail.com> wrote:
>
> Thank you for all your help. By the time I saw Craig's reply, I had
> already cooked up a solution based on Diane's suggestion. Here's what I
> ended up doing:
>
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming