Niklaus Giger | 4 Feb 2002 16:03
Favicon

Subject: Jam 2.4 release status

Dear Richard,

I never include "." in my path. Therefore I suggest that you
change in Makefile

all: jam0
	jam0

to
all: jam0
	./jam0

I had no problem to compile it under cygwin. It seems to work as 
expected with my old Jamfiles.

When I aborted it with Ctrl-C I got the following output:
>C++ Y:/bb/2_0_x/obj/DPU1/hw_io_config.o 
>...interrupted
>      0 [main] jam 443 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
>  10753 [main] jam 443 stackdump: Dumping stack trace to
jam.exe.stackdump

This different compared with Jam 2.3 where it need sometimes more 
than one Ctrl-C to stop, but never more output than "interrupted".

Everything else seams to work

Regards

(Continue reading)

Miklós Fazekas | 5 Feb 2002 08:39
Picon

Jam 2.4 vs. 2.3

The syntax of 'in' was changed in jam 2.4:

I've used to write something like:

>if "TEST" in "TEST1" "TEST2" "TEST3" {
>    ECHO "HELLO" ;
>}

Now i had to replace it with:

>local TLIST = "TEST1" "TEST2" "TEST3" ;
>
>if "TEST" in $(TLIST) {
>    ECHO "HELLO" ;
>}

I don't mind this change, however it should be documented.

Regards,
Miklos.

The change seems to be cause by rewrite of  jamgram.yy

< 	| arg `in` list
to
> 	| expr `in` expr

David Abrahams | 5 Feb 2002 21:49
Favicon
Gravatar

Re: jamming digest, Vol 1 #312 - 1 msg

----- Original Message ----- 
From: <jamming-request <at> perforce.com>
> Subject: [jamming] Jam 2.4 vs. 2.3
> 
> The syntax of 'in' was changed in jam 2.4:

<snip> 

> I don't mind this change, however it should be documented.
>
> Regards,
> Miklos.

For the record, I mind it.

Regards,
Dave

 
> The change seems to be cause by rewrite of  jamgram.yy
> 
> < | arg `in` list
> to
> > | expr `in` expr
> 
> 
> 
> 
> 
> --__--__--
(Continue reading)

Andrew Reynolds | 6 Feb 2002 19:09

building jam for the first time - newbee help please

Folks,

I am trying to build jam 2.3 itself form the source files I down loaded from
the perforce web site.  I am building on Solaris 2.6.  The make file
generates jam0 but I keep getting this error when running jam0:

Archive bin.unix/libjam.a
ld: fatal: file bin.unix/libjam.a: cannot open file: No such file or
directory
ld: fatal: File processing errors. No output written to a.out

I am frustrated with the documentation on this - it is very vague and there
are few references on how to build jam the first time or what environment
needs to be set and I just can't seem to figure out what needs to be set to
fix this.  Or maybe I have just spent too much time writing perl scripts and
have forgotten all my c.

So could some take pity on me and point me the right way on this? (either
which doc covers this or give me some instructions here).

Thanks,

Andrew Reynolds
Configuration Manager
Syndeo Corporation
Buster says: "If you've got melted chocolate all over your hands, you're
eating it too slowly. "

rmg | 6 Feb 2002 23:18
Favicon

Re: jamming digest, Vol 1 #313 - 2 msgs

> > The syntax of 'in' was changed in jam 2.4:
> 
> <snip> 
> 
> > I don't mind this change, however it should be documented.
> >
> > Regards,
> > Miklos.
> 
> For the record, I mind it.

Ah, finally, controversy! Well, closest thing we've seen to it :-)

No final ruling yet, but it does sound like the change breaks existing
Jamfiles, and unless there's strong a reason to do so, I suspect we'll
want to put it back the way it was.

BTW, I'll likely be distracted (more the most part) from jam work
until the last week of the month, at which point I hope to be able to
complete my checklist of reviews needed before I can finalize a
packaged 2.4 release.

One item on the checklist will be to review all of the traffic on this
list since, say Jan 1, to make sure I haven't missed picking up any
important bug reports or fixes. So, please do keep them coming.

Thanks all,

  Richard Geiger
  Open SOurce Engineer at Perforce
(Continue reading)

Ray Caruso | 7 Feb 2002 00:16

"in" syntax change in 2.4

Oh man, don't modify syntax, please. Add new stuff, but don't break 
existing syntax.
That would be one very big reason to not move from 2.3 to 2.4.

My $0.02

Ray
>To: jamming <at> perforce.com
>
> >
> > <snip>
> >
> > > I don't mind this change, however it should be documented.
> > >
> > > Regards,
> > > Miklos.
> >
> > For the record, I mind it.
>
>Ah, finally, controversy! Well, closest thing we've seen to it :-)
>
>No final ruling yet, but it does sound like the change breaks existing
>Jamfiles, and unless there's strong a reason to do so, I suspect we'll
>want to put it back the way it was.
>
>BTW, I'll likely be distracted (more the most part) from jam work
>until the last week of the month, at which point I hope to be able to
>complete my checklist of reviews needed before I can finalize a
>packaged 2.4 release.
>
(Continue reading)

Markus Scherschanski | 7 Feb 2002 13:33
Picon
Favicon

Single Pseudo-Target

Hello folks,

I got a bit of a problem, I'm trying do create a target that is only called
if the command line says it, I mean something like:

jam -f myjamfile cclean

It should be a substitution for the normal clean.

I tried several ways, look what I mean:

rule CClean

{
	local _i ;

	if $(UNLOCK_ONLY) != TRUE
	{
		ECHO removing object files and lib ;
	}

   	for _i in [ FGristFiles $(>) ]
    	{
		UnlockIt $(_i) ; 
		if $(UNLOCK_ONLY) != TRUE
		{ 
			CleanIt $(_i) ;
		}
  	}
}
(Continue reading)

Diane Holt | 7 Feb 2002 21:40
Picon
Favicon

Re: Single Pseudo-Target

You were really really close... :)

Try:

  NOTFILE cclean ;
  ALWAYS cclean ;

  rule CClean
  {
    local _i ;

    if ! $(UNLOCK_ONLY)
    {
      CCleanMessage cclean ;
    }

    for _i in [ FGristFiles $(>) ]
    {
      UnlockIt cclean : $(_i) ;
      if ! $(UNLOCK_ONLY)
      {
        CleanIt cclean : $(_i) ;
      }
    }
  }

  actions CCleanMessage
  {
    echo Removing object files and lib...
  }
(Continue reading)

Jack_Goral | 7 Feb 2002 14:10
Picon

RE: Single Pseudo-Target

I think you can take the idea from my code below:

rule Msdev # projectname
{
	local _t = $(1:S=.dsp) ;	# make it : projectname.dsp
	local _wt = \"$(1) - Win32 $(BUILD)\"  ;
	local _clean = [ FGristFiles clean ] ;
    #
	# find the .dsp file
	#
	SEARCH on $(_t) = $(SEARCH_SOURCE) ;
	#LOCATE on $(_t) = $(SEARCH_SOURCE) ;
	#
	# make all depend on the target (.dsp)
	#
	DEPENDS build : $(_t) ;
	DEPENDS all : build ;
	DEPENDS clean : $(_clean) ;
	#
	# always remake the target so 'msdev' decides what to rebuild
	#
	ALWAYS $(_t) ;	
	#
	# msdev build target, for example:  "NGExpertSvr - Win32 Debug" 
	#
	if $(SUB_BUILD)
	{
		 _wt = \"$(1) - Win32 $(SUB_BUILD) $(BUILD)\"  ;
	}
	MSDEV_BUILD_TARGET on $(_t) = $(_wt) ;
(Continue reading)

David Abrahams | 11 Feb 2002 01:53
Favicon
Gravatar

Nasty Jam behavior

My copy of Jam has the following behavior on Windows:

C:\>jam -f-
x = foo/bar ;
ECHO $(x:G=) ;
^Z
foo\bar
   ^---------------slash direction reversed!

I guess it's mostly harmless when slashes and grist have their usual meaning
(though backslashes can cause trouble for some cygwin tools), but if you're
trying to do anything else, this behavior is at least surprising, and
potentially problematic. Slashes seem to automatically get reversed during
binding anyway, so is there any reason to keep this quirk in Jam?

*---------------------------------------------------*
                  David Abrahams
      C++ Booster (http://www.boost.org)
      Pythonista (http://www.python.org)
  resume: http://users.rcn.com/abrahams/resume.html
          email: david.abrahams <at> rcn.com
*---------------------------------------------------*


Gmane