It looks like we need someone to fix the permissions of the lazarus/designer directory in CVS. I am unable to update. It is giving me the following error:

cvs server: failed to create lock directory in repository '/FPC/CVS/fpc/lazarus/designer' : Permission denied cvs server: failed to obtain dir lock in repository '/FPC/CVS/fpc/lazarus/designer'
cvs [server aborted] : read lock failed - giving up

Curtis

I will get this working with the compiler options. I also think I will move the code to the compiler.pp unit. That way the compiler code will be all contained in the TCompiler class.

I am thinking that I will create a button or something on the Compiler Options dialog that will allow people to save out the options to an options file that they can then pass to the compiler if they want to. If they don't do that and just set the compiler options, then it will call the compiler directly and pass the options to it from the Compiler Options dialog.

I would also like to use the fpcmake utility somehow to allow the developers to create a make file directly from within Lazarus. Maybe we should include a Tools menu like Delphi does that developers can add their own tools to. Or we could just add it to the Project Options menu to Create Makefile.

Curtis

Shane Miller wrote

I created the initial code for the compiler. To try it, do the following: Run lazarus. Go into Compiler Options and set your compiler path.

:-( Lazarus crashes when setting this

Marc

I was afraid of that I added the designer directory and just knew we where going to have problems again. I just tried to telnet in and fix it but I keep getting thrown out.

Cliff

Actually, this is a good idea. We could have a function in the LCL that returns the path to the configuration directory ( getConfigPath() ). In Win32, it could return the path where Lazarus is installed and in Linux it could return the ~/.lazarus path. Then anything within Lazarus that needs the path to the configuration files could just ask this function and depending on where you are compiling the LCL it would return the proper path.

Would this work? The only problem I could see with this is how would that function know where the Win32 installer installed Lazarus? On Linux it is easy because you just look for ~ and depending on what user is logged on you get the path to their home directory. I think Win32 is going to be a little more difficult.

Curtis

Probably the reason is your path is different. Right now, the path in the compiler options is hardcoded to /opt/fpc/lazarus/compileroptions.xml. If that path doesn't exist for you, then it would probably crash. I am going to fix that, maybe tonight. I am going to make it check for ~/.lazarus/compileroptions.xml and if it doesn't exist to create it using default values. If we want, I can make it also check for /etc/compileroptions.xml before it creates it in ~ and use that one for defaults if it exists. What do you all think?

Also, we don't currently have a win32 and linux directories for Lazarus (only for the LCL). I need to create the compileroptions.pp differently for Windoze than for Linux (paths are handled differently). So should I create win32 and linux directories and have a version of the compiler options file for each, or should I put in IFDEF statements into the code? If we create the directories, then we will have to add that into the Makefiles, which I don't know how to do. So how should I handle this?

Curtis

I created the initial code for the compiler. To try it, do the following:

Run lazarus.
Go into Compiler Options and set your compiler path. Select Project New.
Select Project Build. You will have to save your project somewhere previous to building.

The problem I see is that the Compiler Messages dialog doesn't update while compiling. The messages just don't get to it while the other process is running. Not sure what to do about that.

Curtis, you can change the code to improve it. Also, feel free to add all the options to the command line or to a message file and add the message file to the command line.

I think we are pretty close to being able to announce version 0.5 or something. I need a few things fixed yet.

There are problems yet when you save. For example if you save the project as something other that Project1 then the source should get updated. Also, the same goes for other units. This would be a good thing for someone to try. It should be pretty easy.....just building a parser really......

Shane

Is there some way to just translate the file paths internal to the compiler options component. It may make more sense to do that instead of creating a whole new component. This should actually maybe part of the LCL to avoid the platform specific code in the IDE.

Cliff

It's hardcoded on my system too but mine worked. I had to create the opt/fpc/lazarus directory so it could save my settings. Other than that I could set the ppc386 path and it worked fine. Shane

>> 04/18/00 08:07AM >>>

+ From: Shane Miller
+
+ What error do you get when it crashes? Do you have lazaus
+ loaded in opt/fpc/lazarsus?

No, this is the problem as somebody explained. opt/fpc/lazarsus is/was hardcoded.

+ Are you on Linux?

Yes

Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

+ From: Shane Miller
+
+ What error do you get when it crashes? Do you have lazaus
+ loaded in opt/fpc/lazarsus?

No, this is the problem as somebody explained. opt/fpc/lazarsus is/was hardcoded.

+ Are you on Linux?

Yes

Marc

Curtis White wrote

Do you all agree with this method and want me to check it in?

I vote yes.

2 ways:

1) Paramstr(0) returns the complete path of the lazarus binary (ALSO on linux) doing a extractfilepath(Paramstr(0)) then gives what you need.

2) The installer can install a registry key
\HKEY_LOCAL_MACHINE\Software\Lazarus\1.0\bin
appdirectory=\path\to\lazarus installation.
You can retrieve this value. This is standard functionality for install programs.

So I think this is easy :-)

Michael.

Fixed.

Michael.

+ From:
+ Behalf Of Curtis White
+
+ So now I am back to trying to figure out how to do this. So
+ maybe it does make sense to setup Lazarus similar to the
+ RTL or FCL by creating a linux directory and a win32
+ directory. Then to create a .pp file that contains function
+ definitions and their implementations that are specific to
+ the OS. Then in the makefile, we can tell it to compile in
+ the linux file on Linux and the win32 file on Windows. I don't
+ really know of a better way to do this unless we create a file
+ and have IFDEFs in it. If we do it that way, then we should
+ have just a single file that contains ALL the OS specific
+ code. So which way do you all think we should do it?

I think I don't like the single file way. If there are to many ifdefs then
the code will be hard to maintain.

+ I prefer to be consistent with FPC and to have a linux and
+ win32 directory with the same file in each, but implemented
+ differently. I have created this structure on my PC and if
+ everyone agrees, I will check it into CVS this way.
+ But since I have to create a linux and win32 directory, it is
+ going to break CVS for a little while until one of the FPC
+ guys can fix the permissions. Do you all agree with this
+ method and want me to check it in?

If there is no other place and it is specific to Lazarus I vote yes. If it is more generic I feel more for something at the level of sysutils.

Marc

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

So we're back to the private ini files ;-) Or provide they other functionality ?

Marc

+ From:
+ Behalf Of Curtis White
+
+ Actually, this is a good idea. We could have a function in
+ the LCL that returns the path to the configuration directory
+ ( getConfigPath() ). In Win32, it could return the path where
+ Lazarus is installed and in Linux it could return the
+ ~/.lazarus path.

I think not as a part of the LCL. You only need the config for Lazarus it self. Other applications crated by Lazarus have their own config path.

+ Then anything within Lazarus that needs the
+ path to the configuration files could just ask this function and
+ depending on where you are compiling the LCL it would return
+ the proper path.
+
+ Would this work? The only problem I could see with this is
+ how would that function know where the Win32 installer
+ installed Lazarus?

Look at your exe path.

+ On Linux it is easy because you
+ just look for ~ and depending on what user is logged on you
+ get the path to their home directory. I think Win32 is going
+ to be a little more difficult.

In win32 it is common to store your config in the same dir as the exe (default config). Project specific confuguration goes to your project dir.

Marc

That's pretty cool. You ought to put that specific description on the web site, very creative <g>.

As for the other thing, sounds good...

Thanks,

Chris

Cliff:

Lazarus of course refers to the biblical dude that rose from the dead.

Implying

that Lazarus rose the Megido project from the dead. Myself and Shane

Miller

Actually

it is a very low priority since we can do something with that at a later

date.

When we get ready to mess with the res files we should be able to append

them

straight into the executable just as in windows. Cliff

But the LCL is currently the only place were we differentiate between OS platforms. If we don't put it into the LCL somewhere, then we must start making Lazarus have different versions for each OS. This has nothing to do with other applications. It is just a service the LCL is providing to Lazarus. Other applications can worry about their own paths. I don't think everything in the LCL has to be provided strictly for end users does it? Can't we build things into the LCL that will also help us build Lazarus?

But the bigger problem is that it is different on Linux. So we must somehow provide a way for Lazarus to find the path to its config files on Linux and also on Win32. And we need to do this without having two versions of Lazarus and also without using IFDEFs. So the only other way I can think of is to provide a function in the LCL, where we compile it different for each OS, that will tell us how to find the config path.

We don't need to hard code the paths. We just need to define the rules differently. On Linux, it needs to look in ~/ first, then /etc, then use the defaults. On Windows it needs to look in the directory where the exe is installed, then in windows\system, then use the defaults. Notice, that the rules are different and will most likely be different still again if we ever create Lazarus for another platform like OS2, Mac, etc. So to me it makes the best sense to put this into the LCL where we already distinguish the difference between OS's.

I am open to any other suggestions that anyone might have. For now, I will go ahead and code a function into the LCL that will define the rules for the config path. Maybe we need some sort of TLazarus class in the LCL that is designed to hold code created specifically for Lazarus and not to be used by other programs????

Curtis

Makes perfect sense to me we might as well stay consistant with the rest of the source tree.

My vote is yes check it in.

Cliff

I was just wondering: what is the meaning of 'Lazarus,' in relation to this project? How was it picked?

I think Lazarus is a really outstanding name; I assume it is not just a code name, like 'Delphi?'

Another question: how did you guys decide the problem of .dfm files and resources in the .exe in Lazarus? Is the plan to use a resource segment in the .exe when that is added to FPC?

Thanks,

Chris Bordeman

What error do you get when it crashes? Do you have lazaus loaded in opt/fpc/lazarsus? Are you on Linux? Shane

>> 04/17/00 04:34PM >>>

Shane Miller wrote

I created the initial code for the compiler. To try it, do the following: Run lazarus. Go into Compiler Options and set your compiler path.

:-( Lazarus crashes when setting this

Marc

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Chris Bordeman wrote

That's pretty cool. You ought to put that specific description on the web site, very creative <g>.

Done.

Lazarus of course refers to the biblical dude that rose from the dead. Implying that Lazarus rose the Megido project from the dead. Myself and Shane Miller started the project after we relized the Megido project was going no where fast. The Megido project was the first attempt at such a port but I do not think they ever even wrote a single line of code.

As for the DFM files which I am currently working on will be actually in DOM / XML format. The res file stuff has not been adressed as of yet. Actually it is a very low priority since we can do something with that at a later date. When we get ready to mess with the res files we should be able to append them straight into the executable just as in windows.

Cliff

Well. It took them some time to find out that the Registry is a 'Bad Idea (tm)'
Back to ini files then :-)

They'll have to rewrite VB because it can only work with the registry :-)

Where can I find these guidelines ?

Michael.

Well, after looking at it again, putting these OS specific functions into the LCL doesn't really make sense after all (you were right Marc). The LCL isn't really OS specific. Instead, it is widget specific. For example, GTK runs on Windows and Linux. We don't really have anything in there, that I can find, that says to do something a certain way on Linux as opposed to Windows. Instead, everything is based on a widget set, Windows being just another widget set.

So now I am back to trying to figure out how to do this. So maybe it does make sense to setup Lazarus similar to the RTL or FCL by creating a linux directory and a win32 directory. Then to create a .pp file that contains function definitions and their implementations that are specific to the OS. Then in the makefile, we can tell it to compile in the linux file on Linux and the win32 file on Windows. I don't really know of a better way to do this unless we create a file and have IFDEFs in it. If we do it that way, then we should have just a single file that contains ALL the OS specific code. So which way do you all think we should do it?

I prefer to be consistent with FPC and to have a linux and win32 directory with the same file in each, but implemented differently. I have created this structure on my PC and if everyone agrees, I will check it into CVS this way. But since I have to create a linux and win32 directory, it is going to break CVS for a little while until one of the FPC guys can fix the permissions. Do you all agree with this method and want me to check it in?

Curtis