Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
Wow, is that what I really sound like? tl;dr,ldo What I meant to say was: I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window. What is the best approach to get one's Designer into both IDE's? Thanks, and sorry for so many words. -gmt - Original Message - Hello Lazarusians. I'm working on a component with a relatively fat design-time footprint (that is, compared to it's run-time footprint -- it's a smallish sub-project but I expect ~75% of the code to be as design-time-only). My objective is simple, so I'd might as well just spell it out: I'm building a component to manage and encapsulate trivial configuration metadata at the module level in a platform-independent way. The basic approach I'm relying on right now is to give the user a TFrobCollection with various metadata-attributes, kind of like database columns. There will be some fairly straightforward slice-and-dice of the metadata, including aggregation across module boundaries. I want my code to be operational and maintainable in bleeding edge Delphi and Lazarus environments. I don't care too much about old versions. Being able to back-port to, say, D7, without horrible agonies, would be vaguely preferable, but it's far from a priority. I am pretty confident all of the run-time and business-logic aspects of this can be implemented without any need to step outside of the standard VCL/LCL mainstay design-patterns. The only thing that still has me still scratching my head is the design-time stuff. Specifically, I would ideally like to be able to code up my Collection property designer just once, and without utterly pathological usage of precompiler features. BTW even if it worked, I don't think I can just do form inheritance off TCollectionEditor or whatever it's called -- I'm looking to do something considerably more sophisticated than show a list and let the Object Inspector do all the real work -- probably showing the user a hierarchical representation even though the underlying data will be flat. What's troubling me is that Lazarus and Delphi seem to diverge more and more radically the deeper I push towards OTA territory. However, without some fairly elaborate designers I just can't see my component being both cross-platform and application-designer-friendly (I really hate when app. designers are forced to click back-and-forth bazillions of times, like monkeys, to accomplish semantically simple tasks, as too-often seems to be the case with Components supporting lots of TPersistents and Collections, but poor, buggy, or non-existent property designers... I won't name any names, but I'm sure many of you have been that monkey at some point or another (I know I have) and didn't like it :S Anyhow... can some of you with more experience with the LCL - ide state-of-the-art give me some advice on where is the right place to draw the line? i.e.: Should I just ignore all of the various Collection property editors and so forth and do something from scratch which absolutely minimizes OTA dependencies or will Lazarus be able to accommodate some more aggressive approach? Are there any particular OTA interoperation oases that work really well right now? Any hard-core face-slappers that I will need to fix upstream in Lazarus or the LCL before doing /anything/ meaningful along these lines? So far my TOwnedCollection skeleton works like a charm in both IDE's using the default designers, btw. I didn't have to use a single kludge. But my initial efforts at design-time stuff have ended up looking hopelessly pathological in one IDE or the other. Thanks for any help/advice you may have for me, -- -gmt -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
- Original Message - Gregory M. Turner g...@malth.us hat am 19. Oktober 2011 um 08:10 geschrieben: Wow, is that what I really sound like? tl;dr,ldo What I meant to say was: I am developing a Delphi+Lazarus TCollection descendant that needs a fancy designer window. What is the best approach to get one's Designer into both IDE's? Thanks, and sorry for so many words. Thanks for summing up. No problem -- sometimes I need to write the Great American Novel before I can figure out what I'm trying to say. There are worse character flaws, but I sometimes wish I more often had the good sense not to press Send :S You need two design time packages, the Delphi dpk and the Lazarus lpk. Each one needs one unit for the IDE dependent part, for example registering a menu item and registering an event when the selected designer components changes. These two units access the shared unit, which implements your fancy designer window. You can safely put the Delphi and Lazarus package into one directory. The shared unit uses only the LCL/VCL, which are quite compatible, so you probably don't need any compiler directives at all. That sounds perfectly reasonable. I think I was afraid the Oracle would put a hex on me if I did this, but after trying it the other way, I think she's much more likely to condone this tiny sacrifice. In fact, by encouraging me to limit the OTA's inevitably wicked and corrupting influence on my design(-er), your suggestion will probably result in a better outcome than if I had simply hacked up an IDE-specific implementation. Thanks, -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Multi-framework (Embarcadero/Lazarus) property editor for TCollection: best practices?
Hello Lazarusians. I'm working on a component with a relatively fat design-time footprint (that is, compared to it's run-time footprint -- it's a smallish sub-project but I expect ~75% of the code to be as design-time-only). My objective is simple, so I'd might as well just spell it out: I'm building a component to manage and encapsulate trivial configuration metadata at the module level in a platform-independent way. The basic approach I'm relying on right now is to give the user a TFrobCollection with various metadata-attributes, kind of like database columns. There will be some fairly straightforward slice-and-dice of the metadata, including aggregation across module boundaries. I want my code to be operational and maintainable in bleeding edge Delphi and Lazarus environments. I don't care too much about old versions. Being able to back-port to, say, D7, without horrible agonies, would be vaguely preferable, but it's far from a priority. I am pretty confident all of the run-time and business-logic aspects of this can be implemented without any need to step outside of the standard VCL/LCL mainstay design-patterns. The only thing that still has me still scratching my head is the design-time stuff. Specifically, I would ideally like to be able to code up my Collection property designer just once, and without utterly pathological usage of precompiler features. BTW even if it worked, I don't think I can just do form inheritance off TCollectionEditor or whatever it's called -- I'm looking to do something considerably more sophisticated than show a list and let the Object Inspector do all the real work -- probably showing the user a hierarchical representation even though the underlying data will be flat. What's troubling me is that Lazarus and Delphi seem to diverge more and more radically the deeper I push towards OTA territory. However, without some fairly elaborate designers I just can't see my component being both cross-platform and application-designer-friendly (I really hate when app. designers are forced to click back-and-forth bazillions of times, like monkeys, to accomplish semantically simple tasks, as too-often seems to be the case with Components supporting lots of TPersistents and Collections, but poor, buggy, or non-existent property designers... I won't name any names, but I'm sure many of you have been that monkey at some point or another (I know I have) and didn't like it :S Anyhow... can some of you with more experience with the LCL - ide state-of-the-art give me some advice on where is the right place to draw the line? i.e.: Should I just ignore all of the various Collection property editors and so forth and do something from scratch which absolutely minimizes OTA dependencies or will Lazarus be able to accommodate some more aggressive approach? Are there any particular OTA interoperation oases that work really well right now? Any hard-core face-slappers that I will need to fix upstream in Lazarus or the LCL before doing /anything/ meaningful along these lines? So far my TOwnedCollection skeleton works like a charm in both IDE's using the default designers, btw. I didn't have to use a single kludge. But my initial efforts at design-time stuff have ended up looking hopelessly pathological in one IDE or the other. Thanks for any help/advice you may have for me, -- -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
Sorry for the hassle. No worries! Please test. It works. P.S. Git is cool. Yes! 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
- 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
- Original Message - 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. 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 -- Next replace lazarus.exe with the old working version and go into build+clean options and turn off the clean radio button and checkbox. Save that and build the ide. (Voila, it works!) So, assuming I'm right about this, one reasonable solution is: 1) stop -olazarus.new.exe from going into idemake.cfg; instead of that... 2) create somewhere in the jumble of pass-by-reference ide-build info variables to remember that the ide target was locked 3) separate out the make invocations for each of lazarus($ext), startlazarus($ext) and lazbuild($ext). Everything is all set up in Tool above -- most of that can be recycled so this is not so horrible as it sounds perhaps. 4) append -olazarus.new.exe to the OPT= clause of just lazarus($ext), and only when the locked flag got set Arguably a better solution would be to just decide if the IDE is locked, and if so, export an environment variable to make. Then hack up ide/Makefile.fpc to contain some target-specific magical thingy which adds -olazarus.new($ext) only to the lazarus.exe($ext) target and only if that variable is set. However Makefile.fpc had might as well be sendmail.cf to me -- such techniques are too advanced for my weak Makefile-foo. I'd be happy to hack up an attempt at the 1-4 approach if some more knowledgeable person can confirm that this seems correct, I think I have a pretty good idea of where all the code goes. -gmt -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
- Original Message - 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 -- 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
- 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] a patch (was: Re: Is win32 svn broken?)
- 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] a patch (was: Re: Is win32 svn broken?)
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:
[Lazarus] Is win32 svn broken?
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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
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 - Original Message - Am 12.10.2011 15:27, schrieb Gregory M. Turner: 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? 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
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 - Original Message - 2011/10/12 Gregory M. Turner g...@malth.us 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? 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is win32 svn broken?
2011/10/12 Gregory M. Turner g...@malth.us 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 :) 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. 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 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
