Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
Compiler options per file
Ceniza:
--- Quote from: mandrav on February 11, 2009, 06:36:09 pm ---
--- Quote from: Ceniza on February 10, 2009, 08:02:51 pm ---Coming back to the topic, I expected the Don to have a word about it. Don? :P
--- End quote ---
Hm, I didn't really understand what the problem is. Can you be more specific?
--- End quote ---
OK, let me try :)
The current implementation allows you to specify a set of defines, include directories and compilation flags in general per target. That way you may have Debug-ANSI, Release-ANSI, Debug-UNICODE, Release-UNICODE, for example. So far, so good. Now let's take OpenCascade as an example. It's a huge "library" composed of many LIB/DLL files (or .so in Linux). Each LIB/DLL or .so (I'll just continue calling it DLL to imply them all) is composed of a bunch of files that belong to different categories (or packages). Depending on the category they belong to, they are placed in their own directory, requiring some includes to be specific to the category you are compiling. They also require some defines to be... well... defined. The point is: there's is no target per category, but a target per x number of categories. It means that you may have a DLL created from 5 different categories, each one with their own set of include directories and defines. In the Visual Studio project files they solve it by defining custom compilation options per file. It's a bit overkill, and may also be considered bad design, but it's the way they did it.
Actually, it extends an idea I proposed a long time ago, which was to be able to define compiler options that could be used, for example, when compiling a single file, without touching the global ones. It would be like defining build options that you can use globally, per target in a project, for current file compilation and even for a single file in a project. Delphi 2009 has something like that, where you can define build options, save them, load them and attach them to build targets.
Is it a bit clearer now?
MortenMacFly:
--- Quote from: Ceniza on February 13, 2009, 09:45:08 pm ---Is it a bit clearer now?
--- End quote ---
Erm... we *have* the ability to setup compilation options for single files... even scripting should work there... what's wrong with that?!
(Right-click on a file and select "properties".)
Ceniza:
"Use custom command to build this file" is close, but not exactly what I am talking about. At least the interface to do it is not really the same. Still, the MSVC importer won't fill in that one. Have in mind I'm talking about hundreds, probably over a thousand, of files to be configured like this. You are aware that right clicking each file then editing the custom command would take quite a long time, aren't you? :)
The closest approach would be then to modify the importer to fill in that one when the MSVC project file uses such an ugly configuration. Anyway, I am no longer considering to build OpenCascade with C::B, so it's not really that important for me anymore. I was just "talking" about those little details I've found at work that kept me from using C::B instead of VS.
MortenMacFly:
--- Quote from: Ceniza on February 17, 2009, 09:22:22 pm ---Still, the MSVC importer won't fill in that one.
--- End quote ---
OK - got that one. Can you provide an example MSVC project? It should be easy to add to the importer...
Ceniza:
Any OpenCascade project file would do. I'll copy one next week in the office and attach it here.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version