Also I should mention that I didn't write the systemc tests, they're imported from the Accellera implementation. They can be improved in some ways (like making them not leak files), but I tried not to mess with them any more than necessary so I didn't accidentally make them pass or fail when they shouldn't.
Gabe On Fri, Dec 7, 2018 at 3:53 AM Gabe Black <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> *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 <[email protected]> >> 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
