Sometimes, when I look through my header files I'd like to add something little to the (doxygen) documentation. That might be a quick note about the use of some function parameter, or just fixing a little typo.
有时,当我查看我的头文件时,我想在(doxygen)文档中添加一些内容。这可能是关于使用某些函数参数的快速说明,或者只是修复一点错字。
But then I think: Oh no, that'll trigger a recompile on the next make call! And for certain basic headers the whole project would recompile, which can take a long time. So, nevermind!
但后来我想:哦不,那将触发下一个make调用的重新编译!对于某些基本标题,整个项目将重新编译,这可能需要很长时间。所以,没关系!
Is there a solution to this dilemma? Are there approaches where the functions/classes are documented not directly in the headers? Or are there (plans for) a smart make that would notice that only some comment has changed, but no recompilation is necessary?
有这种困境的解决方案吗?是否存在不直接在头文件中记录函数/类的方法?或者是否有(计划)智能制作会注意到只有一些评论已经改变,但是不需要重新编译?
6 个解决方案
#1
How about checking out (you do version control, don't you?) another copy of the codebase in a different directory, just for these kinds of edits?
如何检查(你做版本控制,不是吗?)代码库的另一个副本在另一个目录中,只是为了这些类型的编辑?
It can be a separate branch, or not. Then, when these kinds of small changes occur to you, you just make them here. You can commit them directly: now they are in a safe place, and won't disturb your actual development. Every once in a while, like once a week if your build times really are that long, you can merge these changes to what you are working on. Merge conflicts should rarely occur, as long as you document in one directory and write code in the other.
它可以是一个单独的分支,或不。然后,当你发生这些微小的变化时,你只需要在这里制作它们。您可以直接提交它们:现在它们处于安全的地方,不会影响您的实际开发。每隔一段时间,如果您的构建时间确实很长,每周一次,您可以将这些更改合并到您正在处理的内容中。只要您在一个目录中记录并在另一个目录中编写代码,就很少发生合并冲突。
#2
You could shorten the compile times using ccache, possibly with the CCACHE_UNIFY environment option set.
您可以使用ccache缩短编译时间,可能设置CCACHE_UNIFY环境选项。
ccache hashes the pre-processor output, and serves the previously compiled object if no changes were detected.
ccache散列预处理器输出,如果未检测到任何更改,则为先前编译的对象提供服务。
Man page section about CCACHE_UNIFY
有关CCACHE_UNIFY的手册页部分
CCACHE_UNIFYIf you set the environment variable
CCACHE_UNIFYthen ccache will use the C/C++ unifier when hashing the pre-processor output if -g is not used in the compile. The unifier is slower than a normal hash, so setting this environment variable loses a little bit of speed, but it means that ccache can take advantage of not recompiling when the changes to the source code consist of reformatting only. Note that usingCCACHE_UNIFYchanges the hash, so cached compiles withCCACHE_UNIFYset cannot be used whenCCACHE_UNIFYis not set and vice versa. The reason the unifier is off by default is that it can give incorrect line number information in compiler warning messages.如果设置环境变量CCACHE_UNIFY,那么如果在编译中未使用-g,则在散列预处理器输出时ccache将使用C / C ++统一器。 unifier比普通hash更慢,因此设置此环境变量会失去一点速度,但这意味着当源代码的更改只包含重新格式化时,ccache可以利用不重新编译。请注意,使用CCACHE_UNIFY会更改散列,因此在未设置CCACHE_UNIFY时无法使用设置了CCACHE_UNIFY的缓存编译,反之亦然。默认情况下unifier的原因是它可以在编译器警告消息中提供错误的行号信息。
#3
Why not just touch the file back to a time where make won't think it changed?
为什么不直接触摸文件到make不会认为它改变的时间?
As onebyone suggests you could wrap it into a simple script.
正如onebyone建议你可以把它包装成一个简单的脚本。
#4
make works strictly from the timestamps on the files, and there are definitly no plans to extend it past that. make is used for a lot of things besides just C, and doesn't know anything about the contents of the file. Your build would probably get a lot slower if make had to analyze the changes.
严格按照文件的时间戳进行工作,并且绝对没有计划将其延伸过去。除了C之外,make用于很多东西,并且对文件的内容一无所知。如果make必须分析更改,您的构建可能会慢得多。
You can keep your documentation out of your header files and just in the .c files, which will limit the scope of what needs to be recompiled. I'll admit that personally I prefer to document "interface" functions in header files, but from doxygen's standpoint it doesn't really matter.
您可以将文档保存在头文件之外,只保存在.c文件中,这将限制需要重新编译的内容的范围。我承认,我个人更喜欢在头文件中记录“接口”功能,但从doxygen的角度来看,这并不重要。
As suggested by another, you can bypass this system by using 'touch' to back-date a file.
正如另一个人所建议的那样,您可以通过使用“触摸”来回溯文件来绕过此系统。
doxygen will let you put comments in external files, but that's generally an undesireable solution; part of the whole point of doxygen was to keep the documentation close to the source.
doxygen会让你把评论放在外部文件中,但这通常是一个不可取的解决方案; doxygen的重点之一就是保持文档靠近源。
Otherwise, I suggest you fix your compilations to be faster... you really shouldn't be afraid of them.
否则,我建议你更快地修改你的编辑......你真的不应该害怕它们。
#5
Just make the changes, and accept the recompile. It's not really possible to have a functional development environment when the devs are afraid of compliation; perhaps you need to look into a distributed grid compilation system that will reduce the compilation time?
只需进行更改,然后接受重新编译即可。当开发人员害怕恭维时,实际上不可能有一个功能开发环境;或许你需要研究一个可以减少编译时间的分布式网格编译系统?
#6
My solution is to simply not include headers as dependencies in the Makefile... so changes to a header file do not trigger any recompilation by "make".
我的解决方案是不要在Makefile中包含头作为依赖项...因此对头文件的更改不会通过“make”触发任何重新编译。
Of course the downside to that is that if I make a change that affects memory layouts (e.g. adding a member variable to a class) I need to remember to manually touch the affected .cpp files (or if it's too difficult to figure out which cpp files are affected, do a "make clean; make"), which can be a bit error prone... but it generally works for me.
当然,其缺点是,如果我做出影响内存布局的更改(例如,将成员变量添加到类中),我需要记住手动触摸受影响的.cpp文件(或者如果要弄清楚哪个cpp太难了文件受到影响,做一个“make clean; make”),这可能有点容易出错......但它通常对我有用。
#1
How about checking out (you do version control, don't you?) another copy of the codebase in a different directory, just for these kinds of edits?
如何检查(你做版本控制,不是吗?)代码库的另一个副本在另一个目录中,只是为了这些类型的编辑?
It can be a separate branch, or not. Then, when these kinds of small changes occur to you, you just make them here. You can commit them directly: now they are in a safe place, and won't disturb your actual development. Every once in a while, like once a week if your build times really are that long, you can merge these changes to what you are working on. Merge conflicts should rarely occur, as long as you document in one directory and write code in the other.
它可以是一个单独的分支,或不。然后,当你发生这些微小的变化时,你只需要在这里制作它们。您可以直接提交它们:现在它们处于安全的地方,不会影响您的实际开发。每隔一段时间,如果您的构建时间确实很长,每周一次,您可以将这些更改合并到您正在处理的内容中。只要您在一个目录中记录并在另一个目录中编写代码,就很少发生合并冲突。
#2
You could shorten the compile times using ccache, possibly with the CCACHE_UNIFY environment option set.
您可以使用ccache缩短编译时间,可能设置CCACHE_UNIFY环境选项。
ccache hashes the pre-processor output, and serves the previously compiled object if no changes were detected.
ccache散列预处理器输出,如果未检测到任何更改,则为先前编译的对象提供服务。
Man page section about CCACHE_UNIFY
有关CCACHE_UNIFY的手册页部分
CCACHE_UNIFYIf you set the environment variable
CCACHE_UNIFYthen ccache will use the C/C++ unifier when hashing the pre-processor output if -g is not used in the compile. The unifier is slower than a normal hash, so setting this environment variable loses a little bit of speed, but it means that ccache can take advantage of not recompiling when the changes to the source code consist of reformatting only. Note that usingCCACHE_UNIFYchanges the hash, so cached compiles withCCACHE_UNIFYset cannot be used whenCCACHE_UNIFYis not set and vice versa. The reason the unifier is off by default is that it can give incorrect line number information in compiler warning messages.如果设置环境变量CCACHE_UNIFY,那么如果在编译中未使用-g,则在散列预处理器输出时ccache将使用C / C ++统一器。 unifier比普通hash更慢,因此设置此环境变量会失去一点速度,但这意味着当源代码的更改只包含重新格式化时,ccache可以利用不重新编译。请注意,使用CCACHE_UNIFY会更改散列,因此在未设置CCACHE_UNIFY时无法使用设置了CCACHE_UNIFY的缓存编译,反之亦然。默认情况下unifier的原因是它可以在编译器警告消息中提供错误的行号信息。
#3
Why not just touch the file back to a time where make won't think it changed?
为什么不直接触摸文件到make不会认为它改变的时间?
As onebyone suggests you could wrap it into a simple script.
正如onebyone建议你可以把它包装成一个简单的脚本。
#4
make works strictly from the timestamps on the files, and there are definitly no plans to extend it past that. make is used for a lot of things besides just C, and doesn't know anything about the contents of the file. Your build would probably get a lot slower if make had to analyze the changes.
严格按照文件的时间戳进行工作,并且绝对没有计划将其延伸过去。除了C之外,make用于很多东西,并且对文件的内容一无所知。如果make必须分析更改,您的构建可能会慢得多。
You can keep your documentation out of your header files and just in the .c files, which will limit the scope of what needs to be recompiled. I'll admit that personally I prefer to document "interface" functions in header files, but from doxygen's standpoint it doesn't really matter.
您可以将文档保存在头文件之外,只保存在.c文件中,这将限制需要重新编译的内容的范围。我承认,我个人更喜欢在头文件中记录“接口”功能,但从doxygen的角度来看,这并不重要。
As suggested by another, you can bypass this system by using 'touch' to back-date a file.
正如另一个人所建议的那样,您可以通过使用“触摸”来回溯文件来绕过此系统。
doxygen will let you put comments in external files, but that's generally an undesireable solution; part of the whole point of doxygen was to keep the documentation close to the source.
doxygen会让你把评论放在外部文件中,但这通常是一个不可取的解决方案; doxygen的重点之一就是保持文档靠近源。
Otherwise, I suggest you fix your compilations to be faster... you really shouldn't be afraid of them.
否则,我建议你更快地修改你的编辑......你真的不应该害怕它们。
#5
Just make the changes, and accept the recompile. It's not really possible to have a functional development environment when the devs are afraid of compliation; perhaps you need to look into a distributed grid compilation system that will reduce the compilation time?
只需进行更改,然后接受重新编译即可。当开发人员害怕恭维时,实际上不可能有一个功能开发环境;或许你需要研究一个可以减少编译时间的分布式网格编译系统?
#6
My solution is to simply not include headers as dependencies in the Makefile... so changes to a header file do not trigger any recompilation by "make".
我的解决方案是不要在Makefile中包含头作为依赖项...因此对头文件的更改不会通过“make”触发任何重新编译。
Of course the downside to that is that if I make a change that affects memory layouts (e.g. adding a member variable to a class) I need to remember to manually touch the affected .cpp files (or if it's too difficult to figure out which cpp files are affected, do a "make clean; make"), which can be a bit error prone... but it generally works for me.
当然,其缺点是,如果我做出影响内存布局的更改(例如,将成员变量添加到类中),我需要记住手动触摸受影响的.cpp文件(或者如果要弄清楚哪个cpp太难了文件受到影响,做一个“make clean; make”),这可能有点容易出错......但它通常对我有用。