using compiler programmatically

[Rudolf_M_]

Is it possible to use the Intel C++ compiler from within an other program? (e.g. if I want to build my own IDE or something like that) ... I know, I could call the exe, but I'm curious if I could also load the compiler as dll into my process... or how is the integration into Visual Studio built?

[Marian_M_]

I guess this should be possible by calling some .cmd script which contains a call to iclvars.bat with proper arguments, and then call(s) to particular *.exe's. You need of course to redirect pipes (stdin, stdout, stderr) to your process while spawning generated .cmd script.

NB user needs MSVC to be installed in order to install ICC.

I am using this technique, but the difference is I call MSBuld in generated .cmd script to build MSVC project/solution (an .sln file).

[jimdempseyatthecove]

Why not create a separate process, like Marian suggests, hiding the window (capturing output). Construct the scripts or command line to produce a shared library, then if no errors detected, load the library, find the function entry points, and make your calls.

In lieu of a shared library, you could possibly generate a PIC executable (IOW something like a driver), then load that into a buffer, and assuming you devise a way to locate your entry points (e.g. virtual function dispatch table) make your function calls.

Jim Dempsey

[QIAOMIN_Q_]

Hello Rudolf,

I think you can fork a new process calling the compiler and communicating with it using the bi-directional pipe, then the compiler would receive your command on one end and you can got the compiler output messages from the main thread/process side. This way is like mplayer'standby mode.

[Rudolf_M_]

Well... in this case this means "no, it's not possible" (at least not in my process) ... thanks for the info anyway... I'm currently not sure how we will solve our problem. An other one is that we would have to learn how to deal with the debug database it creates and (as always) we have to accept the uncertainty that this compiler will exist in more or less the same way in the future... :-) ... isn't it fun, the software business?

[Shenghong_G_Intel]

I guess most of the IDE (like CodeBlocks, QCreator etc.) are invoking the real compiler (gcc for example) using a new process (even the Visual Studio is doing in this way, I guess). It looks like what you want is "a compiler library (like dll), which provides interfaces for you to invoke and build codes", this is not necessary for an IDE from my understanding...Even Visual Studio is just invoking the real compiler "cl.exe" instead of invoking some API interfaces from a library.

An other one is that we would have to learn how to deal with the debug database.

>> If you are talking about the "debug information", you may just need to follow the ELF standard (for Linux) or PE standard (for Windows), as any compiler will just generate debug information according to these standard.

Hope it helps. :)

Thanks,

Shenghong

[Marian_M_]

Greetings,

I strongly discourage you from making a .DLL, but encourage you to use separate process (I have very positive result by this technique).

But when you choose a .DLL approach, I must warn you, since Windows doesn't clear heap when DLL is detached, and attached again, so any global variables will have same value when you attach DLL again. I.e. the worst case is when global variable, or static variable is not-POD object and it is class with constructor, re-attaching DLL again will not call c++ constructor, and you end up with a crash.

Please, think of attaching compiler as a separate process as CLank or MSVC does; in other case you will get mysterious crashes and undebugable results...

best,

vdm

.

[Rudolf_M_]

I guess you're right... I did think about it again and... I could work also without a way to load the compiler as dll (I could work with intermediate files instead of compiling directly from the memory... -> our project contains an cross compiler to c++), but it would be nice to have at least a way to get the errors and warnings without having to parse them from the output of the compiler... if there's an easier way to do it, that would help a lot... in fact, the main goal is to read the errors in a way that's not error prone.