Updating to rev. 36173 results in a number of conflicts in various Makefile, Makefile.compiled and Makefile.fpc, in components/ and packager/ subdirectories.
What's wrong?
How to fix that mess? (using TortoiseSVN)
DoDi
Mailing lists / lazarus / 2012-03
SVN update conflicts
18 messages · 7 people · –
- Hans-Peter Diettrich 7
- Mattias Gaertner 6
- ajv 1
- Felipe Monteiro de Carvalho 1
- Kjow 1
- Vincent Snijders 1
- +1 more
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Op 20 maart 2012 03:17 heeft Hans-Peter Diettrich
het volgende geschreven:
Show quoted text 7 lines
Updating to rev. 36173 results in a number of conflicts in various Makefile,
Makefile.compiled and Makefile.fpc, in components/ and packager/
subdirectories.
What's wrong?
How to fix that mess? (using TortoiseSVN)
Revert.
Update.
Vincent
Updating to rev. 36173 results in a number of conflicts in various Makefile,…
Another option:
1->Remove all files with conflicts (including those .mine and .r34567 files) 2->svn up
Felipe Monteiro de Carvalho
Op 20 maart 2012 03:17 heeft Hans-Peter Diettrich het volgende geschreven: Revert. Update.
Show quoted text 13 lines
Op 20 maart 2012 03:17 heeft Hans-Peter Diettrich
het volgende geschreven:
> Updating to rev. 36173 results in a number of conflicts in various Makefile,
> Makefile.compiled and Makefile.fpc, in components/ and packager/
> subdirectories.
>
> What's wrong?
>
> How to fix that mess? (using TortoiseSVN)
Revert.
Update.
Thanks, that helped. Will I have to do the same in the future, before every update, or was it a glitch?
What's the reason for versioning e.g. Makefile.compiled?
DoDi
Show quoted text 17 lines
Vincent Snijders schrieb:
> Op 20 maart 2012 03:17 heeft Hans-Peter Diettrich
> het volgende geschreven:
>> Updating to rev. 36173 results in a number of conflicts in various Makefile,
>> Makefile.compiled and Makefile.fpc, in components/ and packager/
>> subdirectories.
>>
>> What's wrong?
>>
>> How to fix that mess? (using TortoiseSVN)
>
> Revert.
>
> Update.
Thanks, that helped. Will I have to do the same in the future, before
every update, or was it a glitch?
Something changed your makefiles. I don't know what.
What's the reason for versioning e.g. Makefile.compiled?
The Makefile.compiled is used by "make" to create the pkgname.compiled files. This way the IDE knows how a package was compiled and knows if it needs to recompile the package.
Mattias
> Thanks, that helped. Will I have to do the same in the future, before > every update, or was it a glitch? Something changed your makefiles. I don't know what.
Hmm, very obscure.
Show quoted text 5 lines
> What's the reason for versioning e.g. Makefile.compiled?
The Makefile.compiled is used by "make" to create the
pkgname.compiled files. This way the IDE knows how a package was
compiled and knows if it needs to recompile the package.
Since everything must be compiled on the *local* machine, it doesn't make sense to import (from the repo) an Makefile.compiled from a *different* machine. Like it doesn't make sense to import the compiled (binary) files, that match the imported Makefile.compiled.
I'm not sure about Makefile.fpc, which also is auto-created.
DoDi
Show quoted text 20 lines
Mattias Gaertner schrieb:
>> Thanks, that helped. Will I have to do the same in the future, before
>> every update, or was it a glitch?
>
> Something changed your makefiles. I don't know what.
Hmm, very obscure.
>> What's the reason for versioning e.g. Makefile.compiled?
>
> The Makefile.compiled is used by "make" to create the
> pkgname.compiled files. This way the IDE knows how a package was
> compiled and knows if it needs to recompile the package.
Since everything must be compiled on the *local* machine, it doesn't
make sense to import (from the repo) an Makefile.compiled from a
*different* machine. Like it doesn't make sense to import the compiled
(binary) files, that match the imported Makefile.compiled.
What exactly makes no sense?
I'm not sure about Makefile.fpc, which also is auto-created.
Mattias
Show quoted text 10 lines
>>> What's the reason for versioning e.g. Makefile.compiled?
>> The Makefile.compiled is used by "make" to create the
>> pkgname.compiled files. This way the IDE knows how a package was
>> compiled and knows if it needs to recompile the package.
> Since everything must be compiled on the *local* machine, it doesn't
> make sense to import (from the repo) an Makefile.compiled from a
> *different* machine. Like it doesn't make sense to import the compiled
> (binary) files, that match the imported Makefile.compiled.
What exactly makes no sense?
The Makefile.compiled must match the last compilation on the user machine. It doesn't make sense to use one from a compilation on a different machine. Following your explanations, currently "make" is fooled whenever a Makefile.compiled is overwritten ("updated") by a version from the repository.
DoDi
Show quoted text 16 lines
Mattias Gaertner schrieb:
>>>> What's the reason for versioning e.g. Makefile.compiled?
>>> The Makefile.compiled is used by "make" to create the
>>> pkgname.compiled files. This way the IDE knows how a package was
>>> compiled and knows if it needs to recompile the package.
>> Since everything must be compiled on the *local* machine, it doesn't
>> make sense to import (from the repo) an Makefile.compiled from a
>> *different* machine. Like it doesn't make sense to import the compiled
>> (binary) files, that match the imported Makefile.compiled.
>
> What exactly makes no sense?
The Makefile.compiled must match the last compilation on the user
machine. It doesn't make sense to use one from a compilation on a
different machine.
Using something from another machine is exactly what a binary distribution is about. And that is the purpose of the Makefile.compiled.
Following your explanations, currently "make" is fooled whenever a Makefile.compiled is overwritten ("updated") by a version from the repository.
Mattias
Show quoted text 6 lines
> The Makefile.compiled must match the last compilation on the user
> machine. It doesn't make sense to use one from a compilation on a
> different machine.
Using something from another machine is exactly what a binary
distribution is about.
How do you suppose that something compiled on a 64 bit Linux/gtk2 machine shall be used on a 32 bit Windows machine?
DoDi
Show quoted text 11 lines
Mattias Gaertner schrieb:
>> The Makefile.compiled must match the last compilation on the user
>> machine. It doesn't make sense to use one from a compilation on a
>> different machine.
>
> Using something from another machine is exactly what a binary
> distribution is about.
How do you suppose that something compiled on a 64 bit Linux/gtk2
machine shall be used on a 32 bit Windows machine?
Via cross compiling.
Have you looked into a Makefile.compiled file?
Mattias
Hello,
I installed fpc 2.6.0 as root on Mandriva Linux 32 bit using the rpm packages
FPC is running fine using the fp ide.
I installed the Lazarus sources from svn update 36210
- $ cd lazarus
- $ make clean all
After a while a compile error occurs :
------------------------------------------------------ Compiling /home/user/lazarus/packager/installpkgsetdlg.pas Compiling /home/user/lazarus/packager/confirmpkglistdlg.pas Compiling /home/user/lazarus/packager/newpkgcomponentdlg.pas pkgmanager.pas(3197,55) Error: Call by var for arg no. 1 has to match exactly: Got "TLazPackage" expected "TIDEPackage"
pkgmanager.pas(4793) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make[2]: *** [lazarus] Error 1
make[2]: Leaving directory `/home/user/lazarus/ide' make[1]: *** [ide] Error 2
make[1]: Leaving directory `/home/user/lazarus/ide' make: *** [ide] Error 2
--------------------------------------------------------------
Do you know how to resolve this "TLazPackage" / "TIDEPackage" issue?
Thanks
ajv wrote 26 lines
Hello,
I installed fpc 2.6.0 as root on Mandriva Linux 32 bit using the rpm
packages
FPC is running fine using the fp ide.
I installed the Lazarus sources from svn update 36210
- $ cd lazarus
- $ make clean all
After a while a compile error occurs :
------------------------------------------------------
Compiling /home/user/lazarus/packager/installpkgsetdlg.pas
Compiling /home/user/lazarus/packager/confirmpkglistdlg.pas
Compiling /home/user/lazarus/packager/newpkgcomponentdlg.pas
pkgmanager.pas(3197,55) Error: Call by var for arg no. 1 has to match
exactly: Got "TLazPackage" expected "TIDEPackage"
pkgmanager.pas(4793) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [lazarus] Error 1
make[2]: Leaving directory `/home/user/lazarus/ide'
make[1]: *** [ide] Error 2
make[1]: Leaving directory `/home/user/lazarus/ide'
make: *** [ide] Error 2
--------------------------------------------------------------
Do you know how to resolve this "TLazPackage" / "TIDEPackage" issue?
Already reported on lazdevel mailing list .. track commits and then try again ... I hope it will be fixed in next few hours (or if you don't have enough time to wait svn update -r 36200 ... that one works)
zeljko
Show quoted text 9 lines
Thanks
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120322/1059776e/attachment-0001.html>
Show quoted text 31 lines
On Thursday 22 of March 2012 09:03:08 ajv wrote:
> Hello,
>
> I installed fpc 2.6.0 as root on Mandriva Linux 32 bit using the rpm
> packages
> FPC is running fine using the fp ide.
> I installed the Lazarus sources from svn update 36210
> - $ cd lazarus
> - $ make clean all
> After a while a compile error occurs :
>
> ------------------------------------------------------
> Compiling /home/user/lazarus/packager/installpkgsetdlg.pas
> Compiling /home/user/lazarus/packager/confirmpkglistdlg.pas
> Compiling /home/user/lazarus/packager/newpkgcomponentdlg.pas
> pkgmanager.pas(3197,55) Error: Call by var for arg no. 1 has to match
> exactly: Got "TLazPackage" expected "TIDEPackage"
> pkgmanager.pas(4793) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> make[2]: *** [lazarus] Error 1
> make[2]: Leaving directory `/home/user/lazarus/ide'
> make[1]: *** [ide] Error 2
> make[1]: Leaving directory `/home/user/lazarus/ide'
> make: *** [ide] Error 2
> --------------------------------------------------------------
>
> Do you know how to resolve this "TLazPackage" / "TIDEPackage" issue?
Already reported on lazdevel mailing list .. track commits and then try again
... I hope it will be fixed in next few hours (or if you don't have enough
time to wait svn update -r 36200 ... that one works)
Fixed.
Mattias
2012/3/22 Mattias Gaertner :
Fixed. Mattias
Thank you!
Kjow
On Thu, 22 Mar 2012 02:55:05 +0100 Via cross compiling. Have you looked into a…
> How do you suppose that something compiled on a 64 bit Linux/gtk2 > machine shall be used on a 32 bit Windows machine? Via cross compiling.
Please stop kidding :-(
How do the contributors to the repository know about *my* machine?
Have you looked into a Makefile.compiled file?
Yes, and obviously these have been altered by a local "make" or other operation. E.g. my Makefile.compiled and .fpc contains "-dDoDi", so that both SVN and "make" are fooled when the versioned file contains different information about the compiled files. This became obvious only when SVN could not merge the local and remote versions of some of these auto-generated files.
DoDi
Hans-Peter Diettrich hat am 22. M?rz 2012 um 11:47 geschrieben:
Show quoted text 8 lines
Mattias Gaertner schrieb:
>> How do you suppose that something compiled on a 64 bit Linux/gtk2
>> machine shall be used on a 32 bit Windows machine?
>
> Via cross compiling.
Please stop kidding :-(
Sorry, but as you know the above case does not exist for the Lazarus binaries, so I thought you were making this up.
As you know the Makefile.compiled is independent of widgetset/targetos/targetcpu.
Show quoted text 11 lines
How do the contributors to the repository know about *my* machine?
> Have you looked into a Makefile.compiled file?
Yes, and obviously these have been altered by a local "make" or other
operation. E.g. my Makefile.compiled and .fpc contains "-dDoDi", so that
both SVN and "make" are fooled when the versioned file contains
different information about the compiled files. This became obvious only
when SVN could not merge the local and remote versions of some of these
auto-generated files.
As you know, the Makefile/Makefile.fpc/Makefile.compiled must be updated in sync and that it requires the newest fpc to update, because only that knows all targets. And that's why the auto update is disabled in all lpk of the Lazarus sources. The Makefiles are manually updated by the Lazarus developers - of course via the IDE/lazbuild.
Maybe some lpk files have a bug and the auto update is enabled. Or maybe you updated them by accident.
The Makefiles are updated very seldom, so your update may be a year old. Which lpk was wrong?
Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120322/e4893994/attachment.html>
Show quoted text 5 lines
As you know, the Makefile/Makefile.fpc/Makefile.compiled must be updated
in sync and that it requires the newest fpc to update, because only that
knows all targets. And that's why the auto update is disabled in all lpk
of the Lazarus sources. The Makefiles are manually updated by the
Lazarus developers - of course via the IDE/lazbuild.
Sorry, I don't know nor understand what you try to say :-(
The name "Makefile.compiled" suggests to me that it tracks the compiler options, used in the last compile. That compile takes place at the user machine.
Show quoted text 7 lines
Maybe some lpk files have a bug and the auto update is enabled.
Or maybe you updated them by accident.
The Makefiles are updated very seldom, so your update may be a year old.
Which lpk was wrong?
I don't know, I reported the conflicted files initially.
In components\projecttemplates\Makefile I found:
# Don't edit, this file is generated by FPCMake Version 2.0.0 [2012/03/07] in the working base, while the working copy contains [2012/01/25] instead.
The other directory, marked as modified, is components\fpcunit. No other directories flagged by TortoiseSVN, so far. I've reverted the entire components\ directory now, so that I can find out when the next modifications occur.
DoDi