最进要用vs建立一个解决方案,同时也要依赖一些第三方库,为了以后便于维护,因此想让解决方案的各个文件夹的组织更加合理。通过网上搜索一些网友的解决方案,发现大致可以分为两种,分别参见网址https://blog.csdn.net/lp310018931/article/details/47991759和https://www.cnblogs.com/zuibunan/p/3843459.html,姑且叫他们方案A和方案B。截屏自上面两个网址,方案A和方案B的目录组织可以图示如下。 方案A:
方案B:
可见,方案A和方案B的主要有两点不同,1、解决方案sln文件的位置,2、第三方库的位置。
方案A的sln文件及project文件位于最外层,而方案B多了一个src文件夹,sln文件及project文件位于该文件夹内。方案A依赖的第三方库分布在include、bin、lib目录中,而方案B有一个3rd文件夹专门用于存放第三方库的东西。 综合上述两种方案,决定sln文件的位置采用方案B的,这样的话即使有很多个project,最顶层还是那几个目录,不会显得乱。而第三方库的位置,采用方案B的,但是在include和lib文件中,都放到相应的以库名字命名的文件夹下,方便管理,而bin文件则直接放到bin下的当前配置文件夹下。 假设当前sln文件名为test,有A.exe和B.dll两个项目,依赖于X.dll和Y.dll两个第三方库,那么目录的组织如下图所示。
补充1:各位兄弟们,那个copy的问题我终于解决了,原来当目标路径的文件夹不存在时,copy命令就不好用了,提示系统找不到指定的路径。,把这句话: copy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\; 换成以下这句就OK了…… xcopy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\ 注意,命令变成了xcopy了,而且最后的分号去掉啦,之后即使Bin目录下没有Debug或Release目录编译器也会自动生成的!~
补充2:避免下次编译覆盖文件提示加个“/y” 参数,具体修改如下: xcopy $(TargetPath) $(SolutionDir)\Bin\$(ConfigurationName)\ /y 这回就OK了,如果目标文件正在被使用中的话,会提示“共享侵犯”哦!~ |