headers
Koloseike, Jason | 3 Feb 2000 16:54

Compiling Debug and Product targets in the same Jamfile.

We're in the process of migrating to JAM, with some difficulty I might add.

In the old environment, we recursively called the same makefile to generate 
product(non debug) and debug variants of the objects, libraries and
executables.
The different variants had their own destination directories so that the
could
coexist in harmony.  

With JAM I tried creating  ProdApp and DebugApp rules.  I was expecting the
both the debug objects and executable to end up in a bin/debug directory
while
the product objects and executable to end up in a bin/prod directory.

	rule ProdApp {
		LOCATE_TARGET = $(TARGET_PROD) ;
		DEPENDS $(<) : $(>) ;
		Main $(<) : $(>) ;
	}

	rule DebugApp {
		LOCATE_TARGET = $(TARGET_DEBUG) ;
		DEPENDS $(<) : $(>) ;
		Main $(<) : $(>) ;
	}

	.
	.
	.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Lewis | 3 Feb 2000 17:54
Favicon

Re: Compiling Debug and Product targets in the same Jamfile.

Without getting into it in detail, I guess it would be that the 
executables are stated to depend upon the sources rather than the binaries,
so once jam builds the sources then it could link both exe's
from them.

if you run with debug, you can nail it down exactly, although its a lot
of output to look at.

We do a similar thing here, but I seem to remember a rule MainFromObjects
that expresses the exe to obj dependency directly.

What we do is run jam twice with a BUILD_TYPE=debug and BUILD_TYPE=release
and use the same rules.

dave

  > From: "Koloseike, Jason" <Jason.Koloseike <at> Cognos.COM>
  > Date: Thu, 3 Feb 2000 10:54:07 -0500 
  > MIME-Version: 1.0
  > X-Mailer: Internet Mail Service (5.5.2448.0)
  > Content-Type: text/plain;
  > 	charset="iso-8859-1"
  > Sender: jamming-admin <at> perforce.com
  > Errors-To: jamming-admin <at> perforce.com
  > X-Mailman-Version: 1.0rc3
  > Precedence: bulk
  > List-Id: Discuss the build tool Jam/MR with other users <jamming.perforce.com>
  > X-BeenThere: jamming <at> perforce.com
  > 
  > We're in the process of migrating to JAM, with some difficulty I might add.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amaury FORGEOT-d'ARC | 3 Feb 2000 17:55
Picon

Re: Compiling Debug and Product targets in the same Jamfile.


> With JAM I tried creating  ProdApp and DebugApp rules.  I was expecting the
> both the debug objects and executable to end up in a bin/debug directory
> while
> the product objects and executable to end up in a bin/prod directory.
>
>    rule ProdApp {
>         LOCATE_TARGET = $(TARGET_PROD) ;
>         DEPENDS $(<) : $(>) ;
>         Main $(<) : $(>) ;
>    }
>
>    rule DebugApp {
>         LOCATE_TARGET = $(TARGET_DEBUG) ;
>         DEPENDS $(<) : $(>) ;
>         Main $(<) : $(>) ;
>    }
>
>    .
>    .
>    .
>
>    HDRS += ..$(sep)include ;
>
>    source = file1.c file2.c file3.c ;
>
>    DebugApp progd : $(source) ;
>
>    ProdApp prog : $(source) ;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randy Roesler | 3 Feb 2000 19:30
Picon

RE: Compiling Debug and Product targets in the same Jam file.

use GRIST ... chnage the Main rule (and other
rules as required) so that the executable and
object files have differnt GRIST.

for example, add '-release' or '-debug' to the
GRIST

-----Original Message-----
From: Koloseike, Jason [mailto:Jason.Koloseike <at> Cognos.COM]
Sent: Thursday, February 03, 2000 7:54 AM
To: 'jamming <at> perforce.com'
Subject: [jamming] Compiling Debug and Product targets in the same
Jamfile.

We're in the process of migrating to JAM, with some difficulty I might add.

In the old environment, we recursively called the same makefile to generate 
product(non debug) and debug variants of the objects, libraries and
executables.
The different variants had their own destination directories so that the
could
coexist in harmony.  

With JAM I tried creating  ProdApp and DebugApp rules.  I was expecting the
both the debug objects and executable to end up in a bin/debug directory
while
the product objects and executable to end up in a bin/prod directory.

	rule ProdApp {
		LOCATE_TARGET = $(TARGET_PROD) ;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diane Holt | 4 Feb 2000 00:57
Picon
Favicon

Re: Compiling Debug and Product targets in the same Jamfile.

Hi Jason,

So far everyone seems to be suggesting you try using GRIST, but I'm not
sure it would do it for you (but maybe I'm just being slow today). For
things like this, I generally just use full paths -- that way, you end up
with two different targets (when you run 'jam', not in your Jamfile).

So, here's some stuff that works. It's basically just a quickie, so you'll
probably need to adjust things for your specific needs. For one thing, I
didn't bother using $(SLASH) (I was being lazy), so you'll need to change
any /'s (I did it on a FreeBSD machine, but it should work on Windoze once
you change those.) I also assumed you always want both flavors built -- if
you want to be able to do one or the other, you can always add that.

Dir struct is:
/tmp/jason/
          Jamfile Jamrules  src/
                               Jamfile foo.c

Jamrules:
# Build both debug and production executables
rule myMain
{
  local i t ;

  for i in debug prod
  {
    t = $(SUBDIR)/bin/$(i)/$(<) ;

    #Because we aren't using MakeLocate, which ordinarily does the mkdir's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amaury FORGEOT-d'ARC | 4 Feb 2000 10:00
Picon

Re: Compiling Debug and Product targets in the same Jamfile.


-- Diane Holt <holtdl <at> yahoo.com> wrote:
>  For things like this, I generally just use full paths -- that way, you end up
> with two different targets (when you run 'jam', not in your Jamfile).

You are right:
     t = $(SUBDIR)/bin/$(i)/$(<) ;       (where $(i) is either 'debug' or
'prod')
will do the same thing as
     t = $(<:G=$(i));
     LOCATE on $(t) = $(SUBDIR)/bin/$(i) ;

Grists and complete paths are 2 ways to make a target unique.
(A grist appears on the target's name in Jam, but not in the target's
file name used in actions)
The advantage of grists is that you don't have to rewrite all the rules,
and the directory structure can be more complex. It is simpler to extract
the grist from a target's name than from a $(SUBDIR)/bin/$(i) construct.

Amaury.
Permalink | Reply | 7 comments |
headers
Diane Holt | 4 Feb 2000 17:23
Picon
Favicon

Re: Compiling Debug and Product targets in the same Jamfile.

I stand corrected (fighting the flu the past two weeks has clearly clouded
my brain).

So, here's a much more elegant solution (Jason, I'd recommend you use this
one instead since it's a lot cleaner):

# Build both debug and production executables
rule myMain
{
  local i s t ;

  for i in debug prod
  {
    SOURCE_GRIST = $(i) ;
    t = $(<:G=$(i)) ;
    s = $(>:G=$(i)) ;
    if $(i) = debug { ObjectCcFlags $(s) : -g ; }
    if $(i) = prod { LINKFLAGS on $(t) += -s ; }
    Main $(t) : $(s) ;
    LOCATE on $(s:S=$(SUFOBJ)) = $(SUBDIR)/bin/$(i) ;
    LOCATE on $(t) = $(SUBDIR)/bin/$(i) ;
  }
}

(I need some chicken-soup...),

Diane

--- Amaury FORGEOT-d'ARC <Amaury.FORGEOTDARC <at> atsm.fr> wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Diane Holt | 4 Feb 2000 18:16
Picon
Favicon

Re: Compiling Debug and Product targets in the same Jamfile.

Ack! I'm obviously not functioning well. I forgot about making the
directories. So...here's what should be the final answer (famous last
words, right?)

# Build both debug and production executables
rule myMain
{
  local i s t ;

  for i in debug prod
  {
    SOURCE_GRIST = $(i) ;
    t = $(<:G=$(i)) ;
    s = $(>:G=$(i)) ;
    if $(i) = debug { ObjectCcFlags $(s) : -g ; }
    if $(i) = prod { LINKFLAGS on $(t) += -s ; }
    Main $(t) : $(s) ;

    DEPENDS $(s:S=$(SUFOBJ)) : $(SUBDIR)/bin/$(i) ;
    MkDir $(SUBDIR)/bin/$(i) ;
    LOCATE on $(s:S=$(SUFOBJ)) = $(SUBDIR)/bin/$(i) ;
    LOCATE on $(t) = $(SUBDIR)/bin/$(i) ;
  }
}

--- Diane Holt <holtdl <at> yahoo.com> wrote:
> I stand corrected (fighting the flu the past two weeks has clearly
> clouded
> my brain).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain McClatchie | 3 Feb 2000 20:22

Re: Compiling Debug and Product targets in the same Jamfile.

Jason> In the old environment, we recursively called the same makefile
Jason> to generate product(non debug) and debug variants of the
Jason> objects, libraries and executables.

You can and should handle this in Jam with a single Jam run.

The rule is: every file you wish to build should exist as a seperate
"target" in the Jamfile hierarchy.  That means you should have
seperate targets for the debug and production versions of your app,
and those files should be built from seperate debug and production
versions of each object file.

It is perfectly reasonable to have these target names distinguished by
different grist, or by different subdirectory names, or by adding ".d"
before the suffix of every debug object file or executable.  We use
suffixes.

It is totally unreasonable to have to specify your build process twice
over in order to maintain these parallel builds.  Instead, you write
rules in Jam to do it for you.

At 10x, we build three versions of every executable: a debug version,
an optimized "production" version, and a profiling version used for
performance tuning.  This takes no more code in our Jamfiles than
building a single production version would.  Here's how we do it:

"Jamrules" contains:

-------------------------------------------------------------------
CC        = /usr/local/bin/gcc ;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain McClatchie | 3 Feb 2000 22:12

Re: Compiling Debug and Product targets in the same Jamfile.

Ah, one other thing.

My example referenced a rule called LinkPackageLibraries.  You
should change that out to use the LinkLibrary rule, unless you want
to pick up the 10x package system as well.  In the latter case,
I've posted it to the Jam mailing list before, you should get it
from the archives.

-Iain McClatchie
www.10xinc.com
iain <at> 10xinc.com
650-364-0520 voice
650-364-0530 FAX
Permalink | Reply | 0 comments |

Gmane