> Date: Mon, 22 Feb 1999 14:40:20 -0800 > From: Iain McClatchie <ia...@mcclatchie.com> > Organization: Open Loop Design > X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) > MIME-Version: 1.0 > CC: jamm...@perforce.com > References: <1999...@medusa.vignette.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > it appears there may be a conflice between the directory containing > > the code, and making an executable with the same name, like > > > > subdir: axe/bin > > > > and in the Jamfile: > > Main axe : axe.c ; > > > > does this make any sense? > > Yes. I don't like it either. > > The standard MkDir uses the directory names as targets, and so you > can't have two different directories (that may have to be made) > with the same name. You also can't have programs with the same > names as directories which may have to be made. This wouldn't be > a problem except that the path to your directory from the Jamfile > root, where you ran Jam, is "axe". If you ran Jam from the axe > directory, the name of the directory would be "../axe", which is > different than the name of the program "axe". > > You really don't expect this to be an issue because there is no > need to be building "axe" anyway, seeing as it has your source in > it. > > Perhaps you could try sticking grist onto the front of MkDir's > argument. I haven't tried that.

along this line, I started looking at rule Main, and one thing it does is say

NOTFILE $(<) ;

so if the exe (unsuffixed) name and a directory name are the same, it seems this rule will make jam think it can not be a directory, and probably not be able to bind it to a file, and perhaps not be able to discern that the file already exists?

does it seem reasonable to grist that target before saying NOTFILE? This should make it distinct, I would think.

dave, wandering blindly.