[Lazarus] Compiling LCL units via commandline

[Reinier Olislagers]

On 25-7-2012 16:56, Mattias Gaertner wrote:
> On Wed, 25 Jul 2012 16:23:38 +0200
> Reinier Olislagers <reinierolislagers at gmail.com> wrote:
>> [...]
>>> I guess a simply flag is not sufficient. See the many verbosity flags
>>> in the IDE. They were all added on users demand.
>> True. First user demand for lazbuild though :)
> 
> Well, not really the first. ;)

;)

>> Perhaps we could just pass on -v (and --verbose=) flags to fpc unless no
>> -v flags specified and then use current behaviour?
> 
> Note: The fpc.cfg normally contains -v flags too.
Ok, but we can't really influence that, nor should we IMO (unless we
start filtering stuff etc).
As an aside just found out fpc persists in spitting out everything if
both -va -v0 are passed, I'd say that's an fpc design decision.
My default fpc.cfg only shows -viwn general info,warnings,notes.

Also, this output would already occur if the OP compiled with FPC
instead of lazbuild...


>>>> Also, it may be possible to adapt lazbuild to be able to compile your
>>>> example program (and similar programs) without need for creating an .lpi
>>>> or .lpr file.
>>>
>>> Some people suggests to use compiler and IDE directives in the lpr
>>> file, which the IDE and lazbuild can use if no lpi is present.
>> Mmm yes, if we do that we could also move all lpi data into the lpr anyway?
> 
> Mixing human edited content and auto generated
> content is asking for trouble.
> The session data should never be stored in the source.
Sorry, that question was ironically meant... as you say, we've got
source code and settings separated now which is much better for e.g.
version control.

>> Have just created a simple console project (see below).
>> I suppose lazbuild could perhaps use code from the IDE to create a new
>> blank Program type project, change ProjectOptions & CompilerOptions
>> PathDelim, Title, Unit0 Filename and UnitName, and then save it with the
>> same filename as the .pas file but with .lpi extension, and build it as
>> usual.
>>
>> Of course, we're in trouble if we specify non-res resources or do more
>> complicated stuff.
>>
>> Perhaps something like this is best left to a wrapper program?
Any opinions on this?