Re: [A-A-P-develop] BDIR, was: More than one matching rule?
Brought to you by:
vimboss
From: Bram M. <Br...@mo...> - 2003-03-21 15:58:10
|
George Bronnikov wrote: > > > Here's a patch that makes BDIRs reside inside every subdirectory. > > > Not tested extensively, but at least it passes the internal tests > > > and a couple of my own. > > > > Can you explain your motivation for chosing this solution? > > > > Where to create the build directory is not an obvious choice: > > - A In the directory of the recipe that is executed > > - B In the directory of the source file > > - C In the toplevel directory of the project > > (I added labels so I can refer to the variants) > > Wichert Ackerman wrote: > > - have it configurable > > > > I might have the sources on a read-only medium and build elsewhere. > > I'll try to list my considerations for the choice. > > Source files in different directories may have the same > name (we could in fact forbid this as bad style, but I assume we don't). I don't think it is bad style. We must be prepared for the same source file name appearing in multiple directories. > Therefore, full pathnames of objfiles have to encode full pathnames of > sources. This can be done by using long filenames, but spreading them > across directories seems more natural. The only relevant difference is that directories need to be created, while "munged" filenames scan be thrown in one directory. My experience is that creating directories is easy, while creating a good munging scheme is complicated. > The next natural choice: > > Objfile for /a/b/c.../y/z.c should be in /a/b/c/.../BDIR/.../y/z.o > > This won't work with variant A if the source is not C-commanded by the > recipe (i.e not in a subdir of the recipe's dir) -- again, that could be > prohibited as bad style. I'm not sure if I understand this remark. Do you mean that the recipe could build "../file.c"? That is strange, and it looks like all the schemes have a problem with this, except B (unless the directory is read-only). > Of the remaining two variants (B and C) B seems simpler (does not use the > notion of toplevel directory). Moreover, as BDIR is relative, rules > like > > $BDIR/lib.a: ../a/$BDIR/a.o ../b/$BDIR/b.o > :sys ar qc $target $source > > work in a straightforward manner (not sure how to reproduce them with A or > C). $BDIR is currently used as an absolute path, this is required in several situations. Using $BSUBDIR would be possible though. > On the other side, with B you cannot distinguish between objfiles from > variants with the same name but different toplevel dirs -- these might be > different. When the user creates two recipes that build the same files with different properties, he may have to specify a different build directory for all schemes. For B it needs to be specified always, for A only when the recipes are in the same directory, for C when the toplevel directory is the same. > And, of course, this does not work with Wichert's scenario -- read-only > source directory. For that, I think you would need a function, something > like OBJNAME(source). For sources in a read-only directory you would have to make a local copy. You can use a "fetch" attribute for that. The directory of the recipe should be writable, this is your build directory (AAPDIR is created here, for example). I think the C scheme (using the toplevel directory of the project) has the disadvantage that it's not always clear what that toplevel directory is. Especially when you can build a program by itself or you can build the program as part of a package. So let's discard this alternative. I can't say I have heard a clear advantage for A or B. When a recipe only builds files that exist in the same directory, A and B are equal. Thus we should look into the situation that a recipe builds source files in sub-directories and/or directories starting with "../". Making a few examples should reveal what the consequences are for the A and B schemes. -- hundred-and-one symptoms of being an internet addict: 165. You have a web page burned into your glasses /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html /// |