Sharing same source file in two projects

[ccrause]

I agree that the situation is uncomfortable, and I'd also comment that things like the IDE highlighter etc.- to which people seem prepared to give unstinting adulation- have absolutely no problem with defines: why then does compile/build?

Agreed, this problem is not going to disappear on its own.  The problem I see is that currently the compiler doesn't know all the defines in play at the time a unit was compiled.  The IDE code tools isn't easily fooled, because it simply parses every little bit of source information it can find in close to real time.

I suppose one option is to include the list of global defines active at the time a unit is compiled, and expose that information in the ppu.  This would allow the compiler to then check if the list of defines has changed.  This is only part of a solution strategy, since any change in the list of global defines would then trigger a recompile of a unit, even if it isn't acted upon in a unit.  Another part of the strategy could be to track the usage of defines in a unit, to check which ones are actually used (similar to tracking of variables) so that adding a user define to the compiler command line doesn't automatically trigger a recompile of all units.

[MarkMLl]

I suppose one option is to include the list of global defines active at the time a unit is compiled, and expose that information in the ppu.  This would allow the compiler to then check if the list of defines has changed.

Taking into account Marco's comment on ppu files and considering that the directory containing them is basically private to FPC, another option would be to be more aggressive in their deletion or to at least mark them as possibly having ambiguous names hence needing unconditional attention at the next full build.

MarkMLl

[marcov]

I agree that the situation is uncomfortable, and I'd also comment that things like the IDE highlighter etc.- to which people seem prepared to give unstinting adulation- have absolutely no problem with defines: why then does compile/build?

Agreed, this problem is not going to disappear on its own. 

Did we really end up with a precise definition of the problem then? If so, I haven't seen it. First you really need to drill down from superficial problem descriptions to the core of the problem.

[MarkMLl]

Did we really end up with a precise definition of the problem then? If so, I haven't seen it. First you really need to drill down from superficial problem descriptions to the core of the problem.

I for one am not inclined to put further time into it. I've got a workaround, and I don't see why I should invest effort only to eventually be told that what I'm seeing is a feature rather than a bug.

MarkMLl

[prof7bit]

Its a design flaw (or missing feature) in the format of ppu files, they lack info about the compile options that were used, they behave like prerequisites in a makefile and serve that exact same purpose.

In a Makefile you could add on top of that all kinds of other nifty checks and automatisms because it is an external tool and the syntax is probably even Turing complete, so with a Makefile you could add just about anything (and most makefile generators are making use of that to the fullest extend), but with PPU you are limited to the features it supports.

I would therefore correct my initial reaction and instead classify it as a feature request.

[marcov]

Its a design flaw (or missing feature) in the format of ppu files, they lack info about the compile options that were used, they behave like prerequisites in a makefile and serve that exact same purpose.

The problem is less the storing, but more with you do with it: which options are important enough to re-compile?

Do you really want to recompile _everything_ for each app that you add a define too ?

As for Mark, well, that is another way of avoiding to be proven wrong :_)

[prof7bit]

Its a design flaw (or missing feature) in the format of ppu files, they lack info about the compile options that were used, they behave like prerequisites in a makefile and serve that exact same purpose.

The problem is less the storing, but more with you do with it: which options are important enough to re-compile?
Do you really want to recompile _everything_ for each app that you add a define too ?

Yes.

And this behavior could even be implemented in Lazarus without touching FPC at all: There would only be one "build" button instead of two and Lazarus or lazbuild remembers the last used options and if they changed it would compile with -B ("build") and if not it would do what "compile" is currently doing: decide only by timestamp.

In my own Makefiles (for embedded C projects) I am doing it like shown below, this will also trigger a full build whenever options have changed, I don't care which ones (better safe than sorry), when options didn't change (which is 99% of the time) it will rebuild only parts of the dependency tree based on timestamps:

Code: GNU make  [Select][+][-]

1. # Force a rebuild whenver the compiler flags have changed.
2. #
3. # On the obscurity scale from 0 to 10 the following Voodoo
4. # will reach a solid 8 but it is very strong and it is useful
5. # enough to use it despite its WTF-factor.
6. #
7. # The phony force target just makes sure the recipe is always
8. # executed, even when the compiler_flags file already exists,
9. # thats is its only purpose.
10. # When the recipe is executed (on every build because of the
11. # phony dependency) it compares the *contents* of the
12. # compiler_flags file and then it might or might not update
13. # the compiler_flags file depending on the current flags.
14. # The object files will be made depending on the compiler_flags
15. # file and when its timestamp is newer then they will be
16. # rebuild too.
17. ALLFLAGS=$(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS)
18. .PHONY: force
19. $(BUILDDIR)compiler_flags: force
20.         echo '$(ALLFLAGS)' | cmp -s - $@ || echo '$(ALLFLAGS)' > $@
21. $(OBJS): $(BUILDDIR)compiler_flags
22.  

[MarkMLl]

As for Mark, well, that is another way of avoiding to be proven wrong :_)

(Shrug) When I find a better tool I'll start using it. Life's too short.

MarkMLl

[marcov]

Yes.

And this behavior could even be implemented in Lazarus without touching FPC at all: There would only be one "build" button instead of two and Lazarus or lazbuild remembers the last used options and if they changed it would compile with -B ("build") and if not it would do what "compile" is currently doing: decide only by timestamp.

Defines and directories can be in so many places, and building is fragmented, so I think this is unpractical

The biggest one of which is that  lazbuild can't recompile libraries that come with FPC automatically. It only works for the lazarus part.
(though in theory that could be worked around with -Ur).

[ccrause]

Do you really want to recompile _everything_ for each app that you add a define too ?

If a global define can change the behaviour, then yes it is desirable to recompile.  I'm aware of some of the practical concerns of tracking defines (such as tracking defines tested in conditional expressions), but making the compiled output more easily predictable is also important.

A simple test case to illustrate how easily a program and a unit can diverge in terms of expected results because of changes in defines:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. interface
4. function answer: integer;
5.  
6. implementation
7.  
8. function answer: integer;
9. begin
10.   Result := {$ifdef YYY}1{$else}0{$endif};
11. end;
12.  
13. end.

Code: Pascal  [Select][+][-]

1. program project1;
2.  
3. uses Unit1;
4.  
5. begin
6.   writeln(#10'>>>>>> Answer = ', answer, ' (expected ',{$ifdef YYY}1{$else}0{$endif},')');
7. end.

Code: Text  [Select][+][-]

1. ~/fpc/installs/lib/fpc/3.2.2/fpc -vi -dYYY -B  -Mobjfpc project1.lpr && ./project1
2. Target OS: Linux for x86-64
3. Compiling project1.lpr
4. Compiling unit1.pas
5. Linking project1
6. 22 lines compiled, 0.3 sec
7.  
8. >>>>>> Answer = 1 (expected 1)
9.  
10. ~/LazProjs/testdefine$ ~/fpc/installs/lib/fpc/3.2.2/fpc -vi   -Mobjfpc project1.lpr && ./project1
11. Target OS: Linux for x86-64
12. Compiling project1.lpr
13. Linking project1
14. 8 lines compiled, 0.2 sec
15.  
16. >>>>>> Answer = 1 (expected 0)

[MarkMLl]

And this behavior could even be implemented in Lazarus without touching FPC at all: There would only be one "build" button instead of two and Lazarus or lazbuild remembers the last used options and if they changed it would compile with -B ("build") and if not it would do what "compile" is currently doing: decide only by timestamp.

I really can't remember where I got to with this and as I have said I'm extremely reluctant to put time into it. But I think it needs to be asked whether this really is a Lazarus problem, or if it is in fact a problem with FPC's single-command application building.

MarkMLl

[marcov]

I really can't remember where I got to with this and as I have said I'm extremely reluctant to put time into it. But I think it needs to be asked whether this really is a Lazarus problem, or if it is in fact a problem with FPC's single-command application building.

Delphi has the same issues. Doesn't mean however that pro7bits option is theoretically impossible, just very unpractical.

[marcov]

Do you really want to recompile _everything_ for each app that you add a define too ?

If a global define can change the behaviour, then yes it is desirable to recompile.

The problem is that there is no trajectory to recompile everything with one exact set of defines.  lazbuild may load .lpk's with own defines in them, and as said the FPC parts can't be auto compiled by lazarus. All packages potentially use all kinds of internal defines.

Again, as said, a possible workaround is to mark certain components as no compile by using -Ur on them (and having this special buildmode stop at -Ur, or have more kinds of -Ur like flags to signify various forms of precompiled code as immutable).

This makes it more than just adding a mode.

I'm aware of some of the practical concerns of tracking defines (such as tracking defines tested in conditional expressions), but making the compiled output more easily predictable is also important.

And a lot of unnecessary extra excessively long compiling to avoid very occasional problems.

I think it is more important to have a way to build that is known good (which is supposed to be "build" now), and maybe pre-prepare some things to force this e.g. for release building.

 
 

[prof7bit]

Yes.

And this behavior could even be implemented in Lazarus without touching FPC at all: There would only be one "build" button instead of two and Lazarus or lazbuild remembers the last used options and if they changed it would compile with -B ("build") and if not it would do what "compile" is currently doing: decide only by timestamp.

Defines and directories can be in so many places, and building is fragmented, so I think this is unpractical

The biggest one of which is that  lazbuild can't recompile libraries that come with FPC automatically. It only works for the lazarus part.
(though in theory that could be worked around with -Ur).

I don't understand why this is less practical than the current solution with two different build buttons? What I proposed was just a simple logic that automatically decides which of the two buttons to "press".

* Options didn't change, so "compile" is sufficient (let FPC just look at timestamps of each unit)
* Options changed, so "build" is needed

Nothing else. Especially I was not talking about rebuilding FCL packges, they have their own optios anyways and don't need rebuilding when the compile options in your app have changed.

---

Implementing it in FPC would only bring an advantage if it would indeed keep track of whether a particular define is used in the unit or not, for every single unit in the dependency tree. Otherwise it would be the same result for every unit, so you don't have to store it at the unit level in the first place, you could make this decision once at the top level file, like it is done now (manually by deciding which of the two buttons to click) and which is exactly what I proposed: A way to automate this human decision.

[MarkMLl]

Delphi has the same issues. Doesn't mean however that pro7bits option is theoretically impossible, just very unpractical.

Allowing that Delphi doesn't split the compiler and IDE to anything like the same extent, is that a fair comparison?

MarkMLl