Compiler options per file

[Ceniza]

Hallo,

Today I tried to compile the most "basic" project file of Open CASCADE, after converting it to a Code::Blocks project file. To my surprise, both defines and include directories were specified per file. Trying to extract all that information (which is quite a lot) and putting it as project global stuff is NOT really the way to go here. It would be nice to have that possibility in Code::Blocks, and update the VS importer to convert that file specific information to the new (if implemented) Code::Blocks format for it.

Is it in the TODO list somewhere for the new compiler framework to have this option, or maybe to add it to the current implementation?

[zak]

Hi,

do you have some news about this topic?

Hallo,

Today I tried to compile the most "basic" project file of Open CASCADE, after converting it to a Code::Blocks project file. To my surprise, both defines and include directories were specified per file. Trying to extract all that information (which is quite a lot) and putting it as project global stuff is NOT really the way to go here. It would be nice to have that possibility in Code::Blocks, and update the VS importer to convert that file specific information to the new (if implemented) Code::Blocks format for it.

Is it in the TODO list somewhere for the new compiler framework to have this option, or maybe to add it to the current implementation?

thanks, g

[Ceniza]

No news

I'm also compiling a list of little things that VS does that would be nice if CB did them too. I'll probably post them at the end of the week to be considered by everyone.

Coming back to the topic, I expected the Don to have a word about it. Don?

[ollydbg]

Good idea!
I'm waiting for the comming weekend.

[mandrav]

Coming back to the topic, I expected the Don to have a word about it. Don?

Hm, I didn't really understand what the problem is. Can you be more specific?

[Ceniza]

Coming back to the topic, I expected the Don to have a word about it. Don?

Hm, I didn't really understand what the problem is. Can you be more specific?

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]

Is it a bit clearer now?

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]

Still, the MSVC importer won't fill in that one.

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.

[yesno]

A possible solution could be the introduction of a new target type:
no real target would be made (like command-line target) but a bunch of object files
plus the possibility of adding external object files for the real target without adding it's object file path but having an absolute or relative path like the other files.

With kind regards

[Ceniza]

Still, the MSVC importer won't fill in that one.

OK - got that one. Can you provide an example MSVC project? It should be easy to add to the importer...

By request of Bloody Cake, attached to this post is a project file with such an evil thing.

[attachment deleted by admin]

[Ceniza]

Dear Bloody Cake,

There's another little issue with it: how to convert the MSVC syntax to GCC's? Even if the MSVC importer is modified to take that information into account, the syntax will still be that of MSVC. It looks like an MSVC to GCC converter would also come handy. Imagine how nice it would be to give this little thingy a command line to compile something with MSVC, and it converted it to GCC's syntax. That would make compiling an MSVC project with Code::Blocks a piece of cake (bloody, if possible).

What surprises me the most is that my previous post is more than a month old, and you did not reply. Where's the love, man?

[MortenMacFly]

Where's the love, man?

Dunno. The file is still in my ToDo folder. Hence from what I saw I now realise what this would actually mean. But it makes no sense to me in fact. I would like to know how they made this VC project file. How on earth is willing to put separate compile commands for each file? What's the sense of that???

Anyways - I still believe it's possible, but this would mean to override each's file compile command. We would need to setup an interface for plugins to allow them to do so. But to be honest: Although it's on my ToDo list I won't have a high priority for me.

The other thing (from your previous post): We had that discussion already. But that's not easy to do - you would need to take into account different MS compiler versions, too if you want to make it "perfect". We decided in the past that this is nothing we want to do (as we would need to do it for each and every compiler and for each and every version)...

[Ceniza]

I would like to know how they made this VC project file. How on earth is willing to put separate compile commands for each file? What's the sense of that???

I think they did that with a generator program. They even use one to output C++ code out of cdl files (which I think is something they came up with).

We decided in the past that this is nothing we want to do (as we would need to do it for each and every compiler and for each and every version)...

Well, depending on how you do it, it could turn out to be easy, so easy that users could contribute to it without much effort. At least being able to convert the basic stuff would be quite handy, don't you think? Making it "perfect" and complete would come with time and contributions. I could probably give it a try, but later. I still want to enjoy my free time with other activities by now.