[M3devel] paths too truncated in assertion failures
Jay K
jay.krell at cornell.edu
Sun Aug 30 00:12:37 CEST 2015
These messages:
****** runtime error:*** <*ASSERT*> failed.*** file "../src/convert/Convert.m3", line 47***
1) It should really be a full path.
I know people will disagree with me.You want more commonality across machines.I'm not sure that is worth it.In particular, debuggers always work more easily with full paths, for local private builds.Hopefully for debugging someone else's, some search pathwith "prefix replacement" is viable.But debugging your own build is more common and ideallyno special setting is needed to make that work.
Yes, full paths could "leak" across machines but I think that is ok.
I did work on this long ago but people disagreed with at the time.
2) We could/should trim the root of the git checkout, so it sayse.g. m3-sys/m3front/src/convert/Convert.m3 if that is easy.
Some C compilers have that feature, when people are conceredwith cross machine consistency for the sake of caching and similarbuild optimizations.
I still prefer #1.
3) Or at least m3front/src/convert/Convert.m33b) or ../../m3front/src/convert/Convert.m3
if we really want it to be a correct relative path from the target directory.
A big part of the problem is the build system is geared toward packages,not multiple packages. I'd like to solve this problem too somehow someday.
Really -- #1 -- source paths should be full paths.
C compilers vary here btw, in terms of what __FILE__ is and what isin debugging information.Sometimes whatever is passed on the command line is used.Sometimes full paths are computed by the compiler.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150829/e0e5d42f/attachment-0001.html>
More information about the M3devel
mailing list