Forum > General

Sharing same source file in two projects

(1/10) > >>

y.ivanov:
Recently, I've bumped in a subtle issue with a shared source files.

I have two different projects in the same directory. They shared almost all their source files (also in the same directory) but two of them: the lpr and the main pas file for each project. Both executables do the same thing, but one is a console program and the other is windows service. The console program is intended for easier debugging in Windows and for installation as a Linux service.
 
One of the shared pas files have code enclosed in an conditional compilation directive like {$ifdef DEF1} ... {$else} ... {$endif} and that DEF1 is defined only in one of the projects.

The thing is that both projects have their default value for 'Unit output directory: lib\$(TargetCPU)-$(TargetOS)' and when one of the projects reloaded into the IDE and then 'Run/Compile' used, then the shared pas file doesn't get rebuilt, despite the different set of defines. The resulting executable gets linked with the old (pre-)compiled unit (from the other project) and that results in an invalid program.

I know, the best thing is to put different unit output directories for each project, but somehow I missed to do that right.   

The next funny thing is that when I use the 'Run' button instead of 'Run/Compile' the IDE somehow manages to compile it right (?!).

Finally, to summarize my questions:

* How IDE checks the dependencies of the source files during compile? Is only the timestamp involved or there is additional parameters like project name, compiler options, etc.? 
* Is the 'Run' button behaves differently from 'Run/Compile' option and then 'Run/Run'?
* Is that a real IDE issue, or I'm starring at it too much? (For me it was real, since I had an embarrassing moments putting non-working service at the target computer)
I have prepared a sample, depending of what is built first and then reloading the other project, then using 'Run/Compile', F9 - either the GUI program gives RunError(103) or the console program doesn't output its message.

Lazarus 1.9.0 r63034 FPC 3.1.1 i386-win32-win32/win64

prof7bit:
This sounds like a bug to me.

I would expect a build system to always detect when compiler options have changed and rebuild all affected object files.

egsuh:
What if you first Shift-F9 and then F9?

MarkMLl:
I've come across similar issues when conditionals and include files are used in concert (e.g. to switch between static and dynamic linkage of an imported library). The only solution I could find was to use "Clean Directory" which would force a complete build from scratch.

MarkMLl

prof7bit:
Try Run|Build instead of Run|Compile.

I honestly don't know what the purpose of Run|Compile is meant to be, just like "build" it invokes the linker, so coming from any other build system on the planet one would naturally expect it to check all prerequisites for linking (and that would make it the same as "build"), but it seems to leave out some important steps in the middle (undocumented?) but then still link the now inconsistent object files and thereby only cause confusion.

If I could I would remove it from the menu entirely. If it can produce incorrect builds it has no reason to exist in the first place.

Navigation

[0] Message Index

[#] Next page

Go to full version