JomiTech Forums

Are you using the Classic or CLANG compiler?

Can you do the following (to hopefully identify the cause): 1. Run a Build All 2. Once it's complete, run a Make on one of the projects. (Based on your description, this should recompile the files in this project) 3. Copy the entire contents of the Console Output tab from the compile window and save...

Is it possible that you have the "generate dependency information" turned off in the 64-bit compiler options? TwineCompile does rely on the dependency files being created to track which files have been modified.

Regarding the ICE - it's just a try-and-see unfortunately.

On doing a Make All, TC compiles all sources files, whether they need to be re-compiled or not. This negates any gain in speed that TC provides and forces me to build individual DLLs one by one Is this specific to this particular project, or you encounter it with any 64-bit projects? For two of the...

I'm assuming that you're using the 64-bit compiler, correct? Split DWARF is only available there. Can you open the TCTargets104.targets file, locate the <OBJCOPY command, and put the following line just above it (below the existing <Message>): <Message Text="OBJCOPY Condition $(USING_CLANG) And...

Does this happen to any project, or just this project in particular? Something must be causing the dependency check logic to ignore the updated library file so the main project does not get relinked. When you say "force the make on the main project", do you mean just run make again, or mak...

This is deliberate for any project that has been configured to use pre-compiled headers. The first unit is compiled by itself to generate the pre-compiled header and then subsequent units can use this pre-compiled header. If multiple files were initially compiled simultaneously, they would either be...

This is an interesting problem, and I don't think I have a solution for you unfortunately. The reason why the TwineCompile targets file has to be at the end is because it has to overwrite a number of settings set by CodeGear.Cpp.Targets, which is imported by all C++Builder projects right at the end ...

Linker memory issues are very difficult to pinpoint unfortunately. Try enabling the Split DWARF functionality introduced in 10.4.2 - that was built to help with linker memory issues.

To combine both 4.5 and 5.2 on a machine, install 4.5 first, and then install 5.2 on top of 4.5 in exactly the same directory. This will keep both sets of files and will allow both to function.