vc project import attempts

[dlh]

(Moved to new thread to avoid further pollution of your roadmap thread - sorry about that)

I did not apply your patch,

I think there's a pattern developing here...

but I did all the mentioned points that you tried to address and more.
The import should now be more smooth (I tried it on FreeImage project)

Eran

I updated and tried, and it is still not correct, at least for a static library.

The .mk that results from my patch (I think) contains:
OutputFile :=$(IntermediateDirectory)/lib$(ProjectName).a

(well, I think I did have to manually edit the libs to change ".lib" to ".a" in the project options - I suppose if you wanted to automate that, it would be nice )

The .mk that results from your changes contains:
OutputFile :=/lib

There is an error reported from the build attempt of the resulting workspace (the original project contains a number of subprojects that produce static libraries, and then an .exe from those libraries) reports:
Usage: makedir input file...

after compiling to produce the .o files... which I expect is appropriate for the "OutputFile" defined in the .mk file.

Asking which tool to use is a nice additional touch (these libraries happen to be based on .c code, rather than .cpp).

[OT]: But I've been wondering, have you considered the possibility of mixed tool projects, where a project might need to specify the tool(set) on a file-by-file basis (source file set might contain mixture of .c, .cpp, and/or other source types)? [/OT]

[eranif]

The .mk that results from your changes contains:
OutputFile :=/lib

I will have a look at this
EDIT: I can not make this happen here, it always ends up fine. Can you provide me with a sln + vcproj files (I dont need the sources) so I can try and import them here?

[OT]: But I've been wondering, have you considered the possibility of mixed tool projects, where a project might need to specify the tool(set) on a file-by-file basis (source file set might contain mixture of .c, .cpp, and/or other source types)? [/OT]

codelite can handle this in a single compiler definition: under the build settings -> compilers -> compiler name -> file types there is a definition for the build line per file type.

In addition, each compiler definition can define its C compiler and C++ compiler name. So you can define the g++ will be used for compilation of c++ files while gcc will be used for C files.

Eran

[dlh]

see attached vctestprojs.zip

This is not my actual, but seems to reproduce everything I experienced.

[garfield]

Just wanted to add, that renaming lib-s to a-s is not necessary (any more) and if this option is added it should be optional, at least on windows.
The same goes for prepending lib... No need for creating more incompatibilities than there are already.

thats all
MihailNaydenov

[dlh]

Eran - just 'ping'ing in an effort to be sure you noticed I attached an archive with a vc solution and projects that does not import and build properly... (forum reports its not been downloaded yet, which I assume means you haven't looked at it, but wanted to be sure you were aware it was there.)

Those projects still do not build properly with your changes that I retrieved from SVN and tried. (I haven't yet obtained the mar 3 release or sync'd that far and tried, but think I already had your vc changes from svn...)

[eranif]

Hi,

I havnt got around to test it yet. I will test as soon as I find some spare
Eran