混合开发环境
从具有干净文件系统层次结构的 Linux 迁移到 Windows，我想设置一个或多个专用文件夹来保存编译器及其相关库，例如 sysfs 之类的东西......我想找到一种优雅的方式来做到这一点。
我主要使用C/C++ java和python进行开发。即使对于 C++ 项目，管理使用 Visual Studio 和 mingw 构建的库也是一件痛苦的事情。如果您以前从事过这个主题，我的目的是分享您的经验。您是否为每个编译器设置专用的开发树，例如每个标准架构（ia32 x86_64 等），或者您只是按照安装程序将所有内容放入程序\ /文件等中？
先感谢您
Moving from Linux, with its clean Filesystem Hierarchy to windows, i'd like to set up one or more dedicated folders to hold compilers and their related libraries, sysfs like, something like sysfs ... i'd like to find the elegant way to do this.
I mainly develop using C/C++ java and python. and even for C++ projects, managing libraries built with visual studio and mingw is a pain. i aim to share your experience if you've worked on this subject before. Do you set a dedicated development tree per compiler for example per par architecture(ia32 x86_64 etc) or you just follow the installer puting everything in program\ /file etc ?
thank you in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我过去看到的是这样的项目：
这允许所有编译器将他们的项目文件分开，并且都使用相同的源。这也可以防止编译器/体系结构之间的意外交叉链接
What I've seen in the past is projects like this:
This allows all the compilers to keep thier project files separate, and all use the same source. This also prevents accidental cross-linkage between compilers/architectures
这并不完全正确，但我自己正在从 Linux gcc/make 转换到 MSVS 的过程中。范式转变可能很棘手。我将分享上周的啊哈！片刻。
MSVS 非常愿意在项目元数据中存储绝对路径名，这会导致您在尝试移动到另一台计算机时感到沮丧。宏功能允许您在额外包含或库目录等位置以符号方式指定各种根目录。使用它们。
This isn't exactly on point, but I'm in the middle of the process of converting from Linux gcc/make to MSVS myself. The paradigm shift can be tricky. I'll just share last week's aha! moment.
MSVS is all too willing to store absolute path names in project metadata, leading to frustration when you try to e.g. move to another computer. The macro feature allows you to specify various root directories symbolically in places like extra include or library directories. Use them.
我通常让 VS、Qt/mingw 等自行安装到它们想去的地方 - 即我保留默认值。关于我的 src-code-tree 和 build-tree，我总是花费大量时间和思考来设置它们。我首先尝试使用 IDE（在我最近的案例中为 VS2008），观察默认行为，然后才设计我的 src-tree 和 bld-free。到目前为止，对于 VS2008，我使用相对简单的安排：
c:\prj\common_lib_cpp
c:\prj\common_lib_cpp\lib1
c:\prj\common_lib_cpp\lib2
c:\prj\common_lib_csharp
c:\prj\common_lib_csharp\lib3
c:\prj\my_exe_prj1
c:\prj\my_exe_prj2
我有点过于简单化了，但不多。这对我来说已经有效了 6 个多月，没有出现大问题。当我前一段时间在 Nuance 工作时，src-tree 是经过精心设计的，基于 make 的构建系统庞大、复杂且健壮。 Windows 和 Linux（几种风格）构建使用相同的 src-tree。这实际上是一项非常艰巨的任务。 Adrian Neagu (Nuance) 曾经有过关于这个主题的优秀博客/网络文章。
I usually let VS, Qt/mingw, etc. install themselves where they wanted to go - i.e. I keep the default. Regarding my src-code-tree and build-tree, I always spend a lot of time and thought setting those up. I start by experimenting with the IDE (VS2008 in my most recent case), observe the default behavior and only then design my src-tree and bld-free. With VS2008 I so far use relative simple arrangement:
c:\prj\common_lib_cpp
c:\prj\common_lib_cpp\lib1
c:\prj\common_lib_cpp\lib2
c:\prj\common_lib_csharp
c:\prj\common_lib_csharp\lib3
c:\prj\my_exe_prj1
c:\prj\my_exe_prj2
I am oversimplifying a little, but not much. This has worked well for me for 6+ months, no major problems. When I worked at Nuance some time ago, the src-tree was very carefully designed and the make-based build system was large, complex and robust. Windows and linux (several flavors) builds used the same src-tree. This is actually very hard task. Adrian Neagu (Nuance) used to have good blog / web articles on this topic.