I am despairing after two days of trying to get svn to build itself on win32 (under wow64) with the fixes_2_6 branch of fpc.

Is this, by any chance, in some known-not-working-for-now-while-somebody-hacks-on-something state?

What always happens -- well, almost always; I have vague memories of it working correctly at some point -- is that lazbuild installs -olazarus.new.exe into idemake.cfg (it has code to complain if it is prevented from doing so which I am very tempted to disable), and then leaves it there. Then it builds lazbuild and startlazarus, also supplying the @idemake.cfg to fcp. So each of these builds overwrites lazarus.new.exe, which is obviously wrong. At the end of the process, lazbuild is saved as lazarus.new.exe and then renamed to lazarus.exe which results in a quick flash of "dos box" while it (lazbuild cum lazarus.exe) dumps its syntax cheat-sheet stdout. Thereafter, of course, nothing happens until I put lazaurs.old.exe back (miraculously, it is preserved correctly despite this insane shell game).

Of course, that is when things go well. When they go poorly, it just does this:

C:/lazarus/fpc/2.6/bin/i386-win32/fpc.exe -gl -dlclwin32 -Fu../lcl/units/i386-win32 -Fu../lcl/units/i386-win32/win32 -Fu../components/codetools/units/i386-win32 -Fu../components/lazutils/lib/i386-win32 -Fu../components/synedit/units/i386-win32 -Fu../components/lazcontrols/lib/i386-win32 -Fu../components/custom -Fu../components/mpaslex -Fu../ideintf/units/i386-win32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../packager/units/i386-win32 -Fu../units/i386-win32 -Fuframes -Fu. -Fiinclude -Fiinclude/win32 -Fi../images -FE.. -FU../units/i386-win32 -WG @C:\Users\greg\AppData\Local\lazarus\idemake.cfg -di386 lazarus.pp .
.
.
Compiling projectwizarddlg.pas
PPU Loading C:\lazarus\components\sqldb\lib\i386-win32\win32\registersqldb.ppu PPU Source: registersqldb.pas not found
PPU Source: registersqldb.lrs not found
Recompiling registersqldb, checksum changed for LResources registersqldb.pas(76,12) Fatal: Can't find unit registersqldb used by SQLDBLaz TExternalToolList.Run Exception: registersqldb.pas(76,12) Fatal: Can't find unit registersqldb used by SQLDBLaz ERROR: tool reported error

I keep telling it "yeah? Well -FU too, thingy!" but it doesn't care. I have tried all the obvious conventional remedies such as make clean bigide & blow away %AppData%\lazarus, googling 'till my eyes bleed, and so-forth. Anyone got a cure for this? Or even some insight into where I should be looking to fix it? Makefiles perhaps?

Thanks for your help,

-gmt

Did you try this in a clean checkout or one where you already built Lazarus with an older version? If the latter, then I'd suggest you to try with a clean one or do a "make distclean" in the existing SVN checkout (though I don't know whether that will work).

Regards,
Sven

2011/10/12 Gregory M. Turner

Yes, I think I am the one to blame. I simplified the Build Lazarus dialog and the associated code.
Unfortunately it broke the build process. I will revert the changes tomorrow unless I find the problem before soon.

$ make all
$ lazarus.exe
should work also on Windows (more or less).

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111012/ddec0eb6/attachment.html>

It was bone dry to start, I literally deleted c:\Lazarus and checked out trunk from svn. Although it's been through quite a bit of thrashing since then, I'm reluctant to blow it away. I have a 99.5% working cygwin-based *.chm build environment set up in there, for one thing. I'll rm -rf at some point if I absolutely must -- but I ended up with this same disease last time I did so (that time, with a Win64 snapshot).

by way of saying this nicely: Suppose we are building a housekeeping robot. We build our first prototype, and it starts out working brilliantly. But, somehow, by day three, all it does is stand in the corner and drive its robot body into the wall over and over. Nobody can figure out what is causing the problem. So we just scrap Prototype I and build MaidBot Prototype II using the latest code-base. Everybody breathes a sigh of relief when Prototype II starts out doing its job correctly. But by day three, it is once again unable to do anything but smash its head against the wall.

I know it's kind of lame for me to say so -- as unified diffs are more useful than bitching and complaining -- but obviously this strongly suggests that there is some heuristic being employed in the robot's code that lacks robustness in the face of the intended purpose of the robot itself.

I suppose, there is nevertheless some diagnostic value in my starting with a completely clean tree, yet again. But assuming it works, and then breaks a third time, I think this amounts to more of a serious bug than a transient "configuration problem" and the correct way to deal with it would probably be to try to fix it rather than work around it.

-gmt

Ah, fantastic, thanks. Only problem is when I do that all my design packages stay as "install next time" or whatever it's called, forever. But don't worry about that. I'll solve this problem the old-fashioned way -- by playing video games until somebody else fixes it for me :)

Out of pure intellectual curiosity -- what is the story behind the monolithic build? Surely fpc doesn't lack (anymore?) the requisite .dll/ld.so features to accomodate a .bpl-style approach?

-gmt

2011/10/12 Gregory M. Turner

Could the problem have to do with the issues discussed in this thread - http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-October/067748.html- perhaps involving some of the other files in the build process?

Gregory M. Turner wrote

Out of pure intellectual curiosity -- what is the story behind the monolithic build? Surely fpc doesn't lack (anymore?) the requisite .dll/ld.so features to accomodate a .bpl-style approach?

While libraries mostly do work there is the whole infrastructure missing to implement dynamic loadable packages. Also this concept needs to be designed in a cross platform way, so that doesn't ease the problem.

Regards,
Sven

-gmt

the bpl-style is missing due to the fact that it is not "just a dll/so" and provisions are lacking in RTL for the moment to accomodate.

kind regards,
Dimitri Smits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111012/aacee493/attachment.html>

2011/10/12 Gregory M. Turner

Another option is to use a SVN revision that works, in this case max. r32815. :)

About the reasons for the changes:
First, I removed examples from the Build Lazarus dialog to fix this issue: 20261: When I try to Start Lazarus I get TrackBar Demo program. IMO it was a wrong place for the examples anyway, that was another reason to remove it.

Then only IDE was left in the list of items to be built. It does not make sense to have a list with only one item, so I wanted to change the GUI and clean the code.
The code got simplified and it is better in many ways but it broke the build process.
The build code is complex and prone to errors as issue #20261 proves. I guess I must revert the changes and find the problems without hurry.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111013/639da543/attachment-0001.html>

Sounds pretty reasonable to me. Anyhow it seems very likely that the problem with trunk, and the 20261 problem (which I suffered from when I was trying the Win64 snapshot) are both just symptoms of the same underlying bug, which as I described seems to pertain to -olazarus.new.exe being in idemake.cfg when it shouldn't be (or perhaps to @idemake.cfg being applied to builds it shouldn't be, depending on the intended design). So your changes may very well be completely orthogonal to the real problem, even if they do break the standard work-around.

I guess I must revert the changes and find the problems without hurry.

As you mention, I could just roll back. Wages of centralized version control, I guess. If you see a light at the end of the tunnel, I certainly wouldn't want you to waste your development man-hours poring over svn merges on my account. Then again if you've painted yourself into a corner, by all means feel free to blame me for the revert commit :)

-gmt

12.10.2011 17:27, Gregory M. Turner ?????:

I am despairing after two days of trying to get svn to build itself on win32 (under wow64) with the fixes_2_6 branch of fpc. Is this, by any chance, in some known-not-working-for-now-while-somebody-hacks-on-something state?

I have problems too.
rev 32864: make clean bigide - works
when I build Lazarus from ide, lazarus is built, but after that lazbuild is built and overwrites lazarus.

Hi

Please test with r32866.
You must do "make clean all" first and then build from the "Build Lazarus" dialog.
There is also an associated bug report: 20476: Cannot compile Lazarus !!!!

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111013/63ea44df/attachment.html>

13.10.2011 11:06, Juha Manninen ?????:

Hi Please test with r32866. You must do "make clean all" first and then build from the "Build

Already tested. Still broken.

----- Original Message -----

I have a bit more info on this.

In some sense, the problem seems to come down to line 14 of ide/Makefile.fpc:

[target]
programs=lazarus startlazarus lazbuild

Lazarus IDE wants to "make -C ide all" while (effectively) OPT='... -olazarus.new.exe' due to it being in idemake.cfg which is, I believe, going to be applied to all fpc invocations which GNU make uses to solve for "lazarus.exe startlazarus.exe lazbuild.exe". As a test of this hypothesis, build+clean and let it fail. Now apply this patch:

Index: buildlazdialog.pas
===================================================================
--- buildlazdialog.pas	(revision 32869)
+++ buildlazdialog.pas	(working copy)
@@ -262,7 +262,7 @@
       Tool.Title:=lisIDE;
       Tool.WorkingDirectory:=WorkingDirectory;
       case Options.IdeBuildMode of
-        bmBuild:      Tool.CmdLineParams:='all';
+        bmBuild:      Tool.CmdLineParams:='ide';
         bmCleanBuild: Tool.CmdLineParams:='clean all';
       end;
       // append extra options

----- Original Message -----

Sorry, to be clear, in between this step and the next we must "make bigide" from the command-line, otherwise the code is not activated in the ide.

Next replace lazarus.exe with the old working version and go into build+clean options and turn off the "clean" radio button and checkbox.

-gmt

----- Original Message -----

----- Original Message -----

Just one other small note about this. Although AFAIK Windows won't let you delete a loaded PE file, it /will/ let you rename it. I don't even think you need any special privileges to do it (don't quote me). (Don't test this using explorer, it has anti-running-program-renaming code for some unfathomable reason).

This suggests an even better (maybe) solution to the problem. Unless there are other platforms than Win32/64 that need this (?), the entire .exe shell-game codepath could be sent to /dev/null and all platforms could work the same. Maybe this breaks on networked drives or something. Probably you guys are 10 steps ahead of me on this, but I just thought I'd mention it in case you weren't.

-gmt

Gregory M. Turner wrote

Just one other small note about this. Although AFAIK Windows won't let you delete a loaded PE file, it /will/ let you rename it. I don't even think you need any special privileges to do it (don't quote me). (Don't test this using explorer, it has anti-running-program-renaming code for some unfathomable reason). This suggests an even better (maybe) solution to the problem. Unless there are other platforms than Win32/64 that need this (?), the entire .exe shell-game codepath could be sent to /dev/null and all platforms could work the same. Maybe this breaks on networked drives or something. Probably you guys are 10 steps ahead of me on this, but I just thought I'd mention it in case you weren't.

Just tested: It works on a network file system as well.

Regards,
Sven

This almost works:

Index: buildlazdialog.pas
===================================================================
--- buildlazdialog.pas	(revision 32869)
+++ buildlazdialog.pas	(working copy)
@@ -145,7 +145,8 @@
 function CreateBuildLazarusOptions(Profiles: TBuildLazarusProfiles;
   Macros: TTransferMacroList; const PackageOptions: string;
   Flags: TBuildLazarusFlags; var AExOptions: string;
-  out UpdateRevisionInc: boolean; out OutputDirRedirected: boolean): TModalResult;
+  out UpdateRevisionInc: boolean; out OutputDirRedirected: boolean;
+  out ExeIsLocked: boolean): TModalResult;
 function SaveIDEMakeOptions(Profiles: TBuildLazarusProfiles;
   Macros: TTransferMacroList;
@@ -200,10 +201,9 @@
 var
   Tool: TExternalToolOptions;
   Options: TBuildLazarusProfile;
-  i: Integer;
   ExOptions: String;
   WorkingDirectory: String;
-  OutputDirRedirected, UpdateRevisionInc: boolean;
+  OutputDirRedirected, UpdateRevisionInc, ExeIsLocked: boolean;
 begin
   Result:=mrCancel;
@@ -262,13 +262,14 @@
       Tool.Title:=lisIDE;
       Tool.WorkingDirectory:=WorkingDirectory;
       case Options.IdeBuildMode of
-        bmBuild:      Tool.CmdLineParams:='all';
+        bmBuild:      Tool.CmdLineParams:='lazbuilder starter';
         bmCleanBuild: Tool.CmdLineParams:='clean all';
       end;
       // append extra options
       ExOptions:='';
       Result:=CreateBuildLazarusOptions(Profiles,Macros,PackageOptions,Flags,
-                                 ExOptions,UpdateRevisionInc,OutputDirRedirected);
+                                 ExOptions,UpdateRevisionInc,
+                                 OutputDirRedirected, ExeIsLocked);
       if ResultmrOk then exit;
       if (not OutputDirRedirected)
@@ -290,6 +291,35 @@
       // run
       Result:=ExternalTools.Run(Tool,Macros,false);
       if ResultmrOk then exit;
+      Tool.CmdLineParams:='ide';    // one more time...
+      // maybe superfluous?  just make sure there's something
+      // to append to
+      if ExeIsLocked and (ExOptions = '') then
+          Tool.EnvironmentOverrides.Values['OPT']:='';
+      if ExeIsLocked then begin
+          // FPC automatically changes the last extension (append or replace)
+          // For example under linux, where executables don't need any extension
+          // fpc removes the last extension of the -o option.
+          // Trick fpc:
+          if GetExecutableExt(Options.FPCTargetOS)='' then
+             Tool.EnvironmentOverrides.Values['OPT'] :=
+               Tool.EnvironmentOverrides.Values['OPT']+'.dummy'
+          else
+              Tool.EnvironmentOverrides.Values['OPT']:=
+                Tool.EnvironmentOverrides.Values['OPT']+' -olazarus.new'+
+                  GetExecutableExt(Options.FPCTargetOS);
+      end;
+
+      // add -w option to print leaving/entering messages
+      Tool.CmdLineParams:=Tool.CmdLineParams+' -w';
+      // append target OS
+      if Options.TargetOS'' then
+        Tool.CmdLineParams:=Tool.CmdLineParams+' OS_TARGET='+Options.FPCTargetOS;
+      // append target CPU
+      if Options.TargetCPU'' then
+        Tool.CmdLineParams:=Tool.CmdLineParams+' CPU_TARGET='+Options.FPCTargetCPU;
+      Result:=ExternalTools.Run(Tool,Macros,false);
+      if Result  mrOK then exit;
     end;
     Result:=mrOk;
   finally
@@ -302,7 +332,8 @@
 function CreateBuildLazarusOptions(Profiles: TBuildLazarusProfiles;
   Macros: TTransferMacroList; const PackageOptions: string;
   Flags: TBuildLazarusFlags; var AExOptions: string;
-  out UpdateRevisionInc: boolean; out OutputDirRedirected: boolean): TModalResult;
+  out UpdateRevisionInc: boolean; out OutputDirRedirected: boolean;
+  out ExeIsLocked: boolean): TModalResult;
   procedure AppendExtraOption(const AddOption: string; EncloseIfSpace: boolean);
   begin
@@ -339,6 +370,7 @@
   Result:=mrOk;
   Options:=Profiles.Current;
   OutputDirRedirected:=false;
+  ExeIsLocked := false;
   UpdateRevisionInc:=Options.UpdateRevisionInc;
   // create extra options
@@ -511,17 +543,9 @@
     // FPC interpretes '\ ' as an escape for a space in a path,
     // so make sure the directory doesn't end with the path delimeter.
     AppendExtraOption('-FE'+ChompPathDelim(NewTargetDirectory));
+  if NewTargetFilename'' then
+    ExeIsLocked := True;
-  if NewTargetFilename'' then begin
-    // FPC automatically changes the last extension (append or replace)
-    // For example under linux, where executables don't need any extension
-    // fpc removes the last extension of the -o option.
-    // Trick fpc:
-    if GetExecutableExt(NewTargetOS)='' then
-      NewTargetFilename:=NewTargetFilename+'.dummy';
-    AppendExtraOption('-o'+NewTargetFilename);
-  end;
-
   // add package options for IDE
   //DebugLn(['CreateBuildLazarusOptions blfUseMakeIDECfg=',blfUseMakeIDECfg in FLags,' ExtraOptions="',AExOptions,'" ',PackageOptions]);
   if not (blfUseMakeIDECfg in Flags) then
@@ -588,10 +612,12 @@
   OptionsAsText: String;
   UpdateRevisionInc: boolean;
   OutputDirRedirected: boolean;
+  ExeIsLocked: boolean;
 begin
   ExOptions:='';
   Result:=CreateBuildLazarusOptions(Profiles, Macros, PackageOptions, Flags,
-                               ExOptions, UpdateRevisionInc, OutputDirRedirected);
+                               ExOptions, UpdateRevisionInc,
+                               OutputDirRedirected, ExeIsLocked);
   if ResultmrOk then exit;
   Filename:=GetMakeIDEConfigFilename;
   try

----- Original Message -----

This almost works:

To answer my own question, lazmanager.pas says that startlazarus sticks around by design. It's apparently not meant to be rebuilt with the IDE. So we should just change 'lazbuilder starter' in my patch to 'lazbuilder'... although I suppose an argument could be made that it should be built if we are cross-compiling.

-gmt

Hi

I reverted the changes in r32874. Sorry for the hassle. I will concentrate on the issue later.
Please test.

Regards,
Juha

P.S.
Git is cool.
I run "git revert" for the relevant revisions, then combined them and committed to server.
Then I created a local branch and reverted again the earlier created "revert-commit".
So I got my changes saved there, waiting until I have time to work on them. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111013/23ab04a1/attachment.html>

Sorry for the hassle.

No worries!

Please test.

It works.

P.S. Git is cool.

Yes!

Yeah, after working with distributed VCSes for a while, going back and trying to live with subversion seems almost impossible.

I keep thinking, when I use subversion: why don't we just store batches of RCS commits on punch-cards and syndicate via UUCP? The end result would imo be O(1) of svn.

Not that I fault anybody for using it -- I use it internally, in fact. But,... come now... one monolithic linear repository relying on a _convention_ of "branch" _directories_? Each repo hosted at a canonical url, which we need constant access to in order to get anything done? A self-described "better cvs"? It really is quite regressive.

-gmt

Quoting Linus Torvalds (from wikipedia)
The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right

L.

2011/10/14 Gregory M. Turner

You can use git with Lazarus SVN repository and it will be a non-issue. See :

http://wiki.lazarus.freepascal.org/git_mirrors
and
http://wiki.lazarus.freepascal.org/Lazarus_git-svn

Looking at your patches it seems you were not only playing video games. The fact however is that my code was badly wrong. To fix it one needs to analyze the current code which is correct at least when the examples are not built any more.
It is over-complicated and I want to simplify it, but first I will need to understand how it works now.
There is room for simplification because the list of MakeModes now has only 1 item, IDE, and I replaced it with with a single IdeBuildMode setting.

I will run some simulated builds to see the output better, when I have time.

FYI:
Mattias G?rtner explained that the IDE should never call "make all".

about the code

FCommands[mmNone]:=''; FCommands[mmBuild]:='all'; FCommands[mmCleanBuild]:='clean all';

It resulted in 'make -C lcl all'. Each directory aka Makefile has its own definition of "all" and "clean".

Regards
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111014/38d2abd3/attachment.html>

----- Original Message -----

> > Git is cool. > Yes!

Purportedly a solution is in the works: http://www.developer.com/open/subversion-1.7-released-with-some-git-esque-merging.html.

I have no opinion regarding "newmerge" (nor have I any basis for one) but I administer some small gitolite repos and find that to be a pretty messy, confusing process.

Even if fork-merge is an afterthought in subversion, in git, multi-user centralized repository administration is equally kludgy and tacked-on. Despite my previous rant, I think it's just different strokes for different folks. It all depends on how your development process is organized, which tool is more suitable. Plus, I heard a crazy rumor that there are more than just two VCSes out there :)

Anyhow this is obviously way off topic. I should really just have a blog, it might significantly improve the S/N ratio of several mailing lists :)

-gmt

By the way, I'd recommend to upgrade freepascal repository to the recently released svn 1.7

This will slightly lessen the pain for those who still can not move to git.