经常在解决问题的过程中，会有一些自我感觉还不错的方法。 我希望能够把这些方法共享出来，起到抛砖引玉的作用。
在hierarchial sdc或者flow 脚本中，会调用很多不同的文件。tcl中调用文件用的是source 这个命令。 调用一次两次还好。如果调用多次，尤其层级较多的时候，就会非常麻烦。 你拿到了顶层的sdc。source了一遍发现有error。但是不知道哪一行有问题。 那么你在source的时候用source -v -e就可以了。 然而，你发现，有error的那一行竟然是source了另外一个文件。 于是，你把那一行改成了source -e -v，然后再重新执行这个命令。 然后你发现了另外一个文件有error的位置竟然还是一个source。于是你想改一下那个文件，然而发现，permission denied
通常，层级超过3级就开始影响心情了。
这时候我们就需要一种更好的方式了。
我在此介绍一个超级简单的方法，就是重新定义source的行为方式。
proc source {args} { __source -e -v $args }
这样就重新定义了source命令，当运行source命令时，等效于运行source -e -v。
这样，你在source这个hierarchical sdc的时候，等效于里面所有层级的source命令，均被替换为了source -e -v。
当然，如果原来用的source 已经带了-echo或者-verbose的选项，那么就相当于用了重复的选项（option），不过在这里选项的重复是没有问题的。
如果想一次性将所有潜在的error都报出来。可以把这个命令改为： proc source {args} { __source -e -v -continue_on_error $args }
我们也可以增加一些debug的信息，方便定位所在文件名称: proc source {args} { echo "starting execute \"source $args\""__source -e -v -continue_on_error $args echo "finishing execute \"source $args\"}
然后通过log，我们就可以迅速定位所有error的所在文件，以及具体行。
结语：
有时，我们可以通过修改tcl原生命令的方式，通过少量的修改，使得flow进入到所谓的debug模式，增加必要信息的输出，迅速找出问题的所在。
