Hmm, I think that may cause problems with the systemc tests. I push some runtime dependencies into the build directory by marking them as dependencies, and the tests refer to them using relative paths. If you run the tests with the source directory as the CWD, they definitely do deposit files where they shouldn't. I sent an email a while ago which described how to use the verify.py script in the src/systemc directory to run the tests if you want to give it a try.
As far as gdb, I don't necessarily have a great answer but this page: https://www-zeuthen.desy.de/unix/unixguide/infohtml/gdb/Source-Path.html mentions something called set substitute-path which looks like it can rewrite source paths that are in the binary. I haven't looked into it, but it might even be possible to tell g++ (or clang, if you prefer) to pretend the sources came from the source directory even though they didn't so that the debugging info in the binary directly contains the source path without substitution. I have no idea if there's actually a way to tell it to do that though. Gabe On Thu, Dec 6, 2018 at 11:49 PM Ciro Santilli <ciro.santi...@arm.com> wrote: > Hey, > > > The method mentioned does not make extra copies of the source, and as far > as I can see from my tests, does not place build outputs in the main source > tree either. > > > In other words, when you use SConscript(variant_dir=, duplicate=0), > scons does the following: > > > - use the source code directly from the main tree, without any symlinks or > copies > > - place only the build outputs in the build directory > > > What annoys me with the symlinks are the following: > > > - I GDB step debug a file. OK, need to open it in my editor. Ctrl + C Ctrl > + V. OK, need to jump to a tag. Arghhh, I'm not on the source tree, need to > find the corresponding file on the source tree to get my ctags. More > generally: it breaks / makes GDB IDE integration harder. > > - the build tree become very cluttered. When analyzing it, it becomes > difficult to find which files are actually being built / generated, since > ls -l shows a large list of symlinks. I end up having to resort to `find > . -type f`. > > > scons rationale for duplication is documented at: > https://scons.org/doc/2.4.1/HTML/scons-user.html#idp1378838508 > > > > The most direct reason to duplicate source files in variant directories > is simply that some tools (mostly older versions) are written to only build > their output files in the same directory as the source files. > > <https://scons.org/doc/2.4.1/HTML/scons-user.html#idp1378838508>but I > think it is being too conservative, I had never seen any modern build > system besides scons doing that, and they work just fine. > ------------------------------ > *From:* Gabe Black <gabebl...@google.com> > *Sent:* Friday, December 7, 2018 12:25:41 AM > *To:* Ciro Santilli > *Cc:* gem5 Developer List > *Subject:* Re: Prevent symlinking of source files in the build directory > > I'm not following why the symlinks are a problem... Could you explain that > more? I've used gdb with gem5 and not had any troubles from that. Using > files from the build directory keeps (or at least helps keep) things from > leaking into the source directory that don't belong there, and when > building 10 different variants, it avoids making 10 copies of the source > tree. I'm pretty strongly in favor of leaving this as is, but I'm always > willing to be enlightened :-). > > Gabe > > On Thu, Dec 6, 2018 at 10:13 AM Ciro Santilli <ciro.santi...@arm.com> > wrote: > > The build symlinks every .cc files from the build directory into the > source directory by default, and it annoys me quite a lot, since when > using GDB I go into the build directory instead of source. > > Today I was studying the build system, and I learned that that this is > an SCons feature of variant dirs, which does hardlinks by default, but > which we force to generate symlinks on gem5 with: > > main.SetOption('duplicate', 'soft-copy') > > I then saw that it is possible to turn off the symlinks / hardlinks and > just use the source directly, at least on a per variant directory basis > with: > > SConscript(variant_dir=, duplicate=0) > > So I ask you the following: > > 1. do you know of a way to turn the duplication off by default in one go > for all variant dirs? > 2. if such method exists, and I made a patch that implements it by > default, would you be favorable to such change? Or do you rely on the > symlinks for some functionality? > > CC @Gabe as I've been told you were planning to do something about the > variants in the build system some time ago. > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
