Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-12

Changed Compilers Options, Run, Build versus Build All

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Tom Verhoeff

(This accidentally got posted in another thread, and hence may have been overlooked. I am still interested in responses.)

Tom Verhoeff wrote
We use Lazarus in our first year programming education (as an experiment). There are various issues that we encounter, some small, some bigger.

Here is another issue. When working on a program involving multiple units, it may turn out that the "Use AnsiStrings" was not set consistently.

Students are advised to enable this globally in the Compiler Options, but they sometimes forget. Some (given/generated) units also contain their own {$H+}, others don't. This may give rise to inconsistencies (usually flagged by the compiler, but not understood by beginners).

When you change Compiler Options later, and then do Run, the relevant unit may not be (re)compiled, because its source code did not change. One is required to do a Build All first. But a beginner will not be aware of this.

Is it possible to have the IDE suggest a Build All when doing Run, if the Compiler Options were changed after the previous build? Or even better have a three-way global setting:

When doing Run and the Compiler Options changed after the previous build:

* Always do a Build All <-- this would be better for beginners
* Always ask to either Build or Build All (the latter as default choice)
* Always do a Build <-- this seems to be the current situation

Best regards,

Tom Verhoeff

E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25 | Technische Universiteit Eindhoven FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands

Reply by email

Mattias Gaertner
to Tom Verhoeff
Show quoted text 8 lines
[...] Here is another issue. When working on a program involving multiple units, it may turn out that the "Use AnsiStrings" was not set consistently. Students are advised to enable this globally in the Compiler Options, but they sometimes forget. Some (given/generated) units also contain their own {$H+}, others don't.

Is this a student bug or an IDE bug?

Show quoted text 7 lines
This may give rise to inconsistencies (usually flagged by the compiler, but not understood by beginners). When you change Compiler Options later, and then do Run, the relevant unit may not be (re)compiled, because its source code did not change. One is required to do a Build All first. But a beginner will not be aware of this.

Yes, that's why the IDE adds -B when the compiler parameters changed (except for search path changes). 0.9.26 has this feature. 0.9.24 not.

Is it possible to have the IDE suggest a Build All when doing Run, if the Compiler Options were changed after the previous build?

It does.
Please provide an example, where it does not work.

Show quoted text 9 lines
Or even better have a three-way global setting: When doing Run and the Compiler Options changed after the previous build: * Always do a Build All <-- this would be better for beginners * Always ask to either Build or Build All (the latter as default choice) * Always do a Build <-- this seems to be the current situation

Mattias

Reply by email

Tom Verhoeff
to Mattias Gaertner
Mattias Gaertner wrote 13 lines
On Thu, 11 Dec 2008 22:33:21 +0100 Tom Verhoeff wrote: >[...] > Here is another issue. When working on a program involving multiple > units, it may turn out that the "Use AnsiStrings" was not set > consistently. > > Students are advised to enable this globally in the Compiler Options, > but they sometimes forget. Some (given/generated) units also contain > their own {$H+}, others don't. Is this a student bug or an IDE bug?

Neither, it is a fact of life :-). It is a consequence of the fact that units from different authors may have been made under different assumptions. Some units are written with the assumption that they will be compiled with -Sh, others do not make that assumption and include {$H+} in the source.

Show quoted text 13 lines
> When you change Compiler Options later, and then do Run, the relevant > unit may not be (re)compiled, because its source code did not change. > One is required to do a Build All first. But a beginner will not be > aware of this. Yes, that's why the IDE adds -B when the compiler parameters changed (except for search path changes). 0.9.26 has this feature. 0.9.24 not. > Is it possible to have the IDE suggest a Build All when doing Run, > if the Compiler Options were changed after the previous build? It does. Please provide an example, where it does not work.

Students are using 0.9.24 (mostly); the disk image with software for their laptops is prepared in the summer. Having them upgrade later is a cumbersome operation (and the ones that did, because they had problems with their Lazarus installation, were bitten by various upgrade issues).

Thanks for the explanation. This is an incentive to consider an upgrade.

Tom

E-MAIL: T.Verhoeff @ TUE.NL | Dept. of Math. & Comp. Science PHONE: +31 40 247 41 25 | Technische Universiteit Eindhoven FAX: +31 40 247 54 04 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands

Reply by email

Hans-Peter Diettrich
to Tom Verhoeff
Show quoted text 15 lines
>> [...] >> Here is another issue. When working on a program involving multiple >> units, it may turn out that the "Use AnsiStrings" was not set >> consistently. >> >> Students are advised to enable this globally in the Compiler Options, >> but they sometimes forget. Some (given/generated) units also contain >> their own {$H+}, others don't. > Is this a student bug or an IDE bug? Neither, it is a fact of life :-). It is a consequence of the fact that units from different authors may have been made under different assumptions. Some units are written with the assumption that they will be compiled with -Sh, others do not make that assumption and include {$H+} in the source.

I'd go the Delphi way, and make "string" dependent on global settings only. If somebody wants specific Ansi- or ShortStrings, s/he should use the according types, in favor of the generic "string" type. Such strict typing will make even legacy code better reusable. I dunno about the perfomance of ShortString with FPC, but I don't think that there exist many cases, where ShortString really provides any advantage over AnsiString.

A hint for students and teachers: *generic* data types, like "integer" or "string", should only be used when *all* operations with such variables will work with any current or future implementation of these generic types. Consider what will happen when "string" becomes a WideString, or the like, as recently happend in RAD Studio (Delphi)...

DoDi

Reply by email

Marco van de Voort
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 9 lines
> be compiled with -Sh, others do not make that assumption and include {$H+} > in the source. I'd go the Delphi way, and make "string" dependent on global settings only. If somebody wants specific Ansi- or ShortStrings, s/he should use the according types, in favor of the generic "string" type. Such strict typing will make even legacy code better reusable. I dunno about the perfomance of ShortString with FPC, but I don't think that there exist many cases, where ShortString really provides any advantage over AnsiString.

string=Shortstring is about TP compatibility. string=ansistring for Delphi 2..D2007 compatibility. string=tunicodestring for D2009 compatibility (if a future FPC does that).

IOW it is about backwards compatibility, not current usages scenario's.

But I agree it could make an educational version easier.

Reply by email