I just commited a new version of the Compiler Options dialog to CVS. It now saves the options in an XML file. But there are a couple of problems I can't seem to be able to figure out. Can someone take a look at this and see if you can see something obvious I am doing wrong?

Here are the problems.

In the TCompilerOptions class, in the Create method, it creates a TXMLConfig object near the top. When this object is created, you pass in a path to the XML file you want it to use. I have currently hardcoded the path to /opt/fpc/lazarus/cplopts.xml. So Windows users will need to change this before you compile it, if you are going to go into the Compiler Options dialog. The reason for the hardcoded path is that for some reason the following method does not seem to be returning the path:

ExtractFilePath(ParamStr(0));

I wanted to extract the path of the exe and then use that path, but this doesn't seem to be returning the path. I ran out of time to check, but I am wondering if it is because I am running Lazarus by just typing in "lazarus" at the command line, so there is no path to extract. But I don't know for certain. Does anyone know? And if that is the case, how can I get the current directory in a way that is not specific to an OS?

The other problem I am having is in the LoadCompilerOptions method of that same class. For some reason, it doesn't seem to be loading the options back in. They are saving out just fine in the SaveCompilerOptions method and I am using the exact same paths and methods (except Get instead of Set) to load them. But it just keeps returning the Defaults instead of the values loaded from the file. Can anyone tell me why this is happening? Is there a bug in the TXMLConfig class, or is there a problem in my code?

Curtis

Hello,

I have been lurking for a few weeks, and watching development progress. I have also been trying to get my development environment set up. As there
is a lot for me to learn such as CVS and GDK, i have not wanted to bother
you with my questions, as answers to those questions can be found elsewhere.

I have managed to compile the compiler, and compile the example files, and
rtl. but when i run lazarus\examples\hello.exe I get an error:

Linked to missing export GDK-1.3.DLL: gdk_cursor_unref.

The dll in question was downloaded from the Lazarus site. Is this problem
caused because the package of GDK dlls i downloaded is now out of date?

---

Also should i be subscribed to other mailing lists besides this one if i want to do any serious work?

-Alan Ferguson

For the storage of Lazarus options, I would recommend using something like ~/lazarus/.compileroptions.xml instead. This is the preferred Unix way. For the application executable EXEname, Application.EXEName is used in Delphi, but I think it is not implemented right now. In the above directory, these would be user-specific options. The global defaults should go to /etc/lazarus/.compileroptions.xml

I think that these options/directories should be defined in the Makefile, as it is done this way in any other project I have worked in Unix. This would allow to define something else for Windows. (But I don't know enough about Makefiles, any idea?)

Michal Bukovjan

Yes, it probably is.

You can download more recent dlls from
http://user.sgic.fi/~tml/gimp/win32/downloads.html.

Download the developer packages:
glib-dev-20000215.zip, gtk+-dev-20000215.zip and possibly extralibs-dev-20000201.zip.

Curtis White wrote

> For the storage of Lazarus options, I would recommend using > something like ~/lazarus/.compileroptions.xml instead.

This should be the only place.

> In the above directory, these would be user-specific options. The > global defaults should go to /etc/lazarus/.compileroptions.xml

This would be bad. In a single user work station this would be OK but given Linux's multiuser organization and the fact that a business might want to use FPC with multiple developers I would not be happy if my defaults settings would change because somebody else set theirs in a different manor. All of the settings need to be placed in the users home ~/ directory tree.

I agree with this, but then how do we do it on Windows? I'm not sure exactly how to handle this without putting in $IFDEF's to determine if we are in Linux or Windows. And I don't think we are using IFDEFs like that. So how do I handle this?

The best way is to do what the FCL does. Create 2 seperate files. One for Linux in a Linux directory and one for Windows in a Win32 directory. When the program is linked the Makefile will use the correct directory in it's units setting. The LCL code will just call the same procedure and the Makefile makes sure the correct .ppu is linked for the correct platform. In fact we need to do more of this with other items.

If I can ever get my butt in gear and finish it this is how the TRegistry will work. The Win32 files will use the REAL Windows Registry and the Linux files will use an XML look alike. The correct .ppu pointed to linked in by the Makefile.

Some things just have to be coded twice in different files.

Michael Van Canneyt wrote

If you implement TRegistry, I suggest you send it to me, so I can include it in the FCL - after all, it isn't a visual component...

I will be. This is where I intended it to go. :-)

I agree with this, but then how do we do it on Windows? I'm not sure exactly how to handle this without putting in $IFDEF's to determine if we are in Linux or Windows. And I don't think we are using IFDEFs like that. So how do I handle this?

I agree that this would probably be the best way to handle this, but then how would that info get into the program from the Makefile? Is it defined as environment variables that we can look up using FPC commands? I'm just trying to determine how to handle paths that will work in both Linux and Windows. As soon as I can figure this out, I can probably finish the compiler options dialog.

Curtis

I agree. This should not be the only place, though. For me it seems logical to have some this structure :

Hardcoded defaults -> System-wide settings (/etc/lazarus) -> User specific settings (~/lazarus)

The settings would then be looked up in this order. When user settings are not found, a system wide fallback would be used. If not found, hardcoded defaults would take place. This method is used in Afterstep, Gnome, and bunch of other apps I looked so far. The problem you describe above can be solved by copying system wide settings into your user directory the first time Lazarus is launched.

Agree. In the case of dirs, only IFDEFs with different consts would suffice, in other cases (i.e. registry) different units as in FCL have to be used.
Hmm, is it possible to pass some symbols from the Makefile into the Pascal source code?

Michal Bukovjan

Sorry, but wouldn't be ~/.lazarus/compileroptions.xml more logical?

- Sebastian

If you implement TRegistry, I suggest you send it to me, so I can include it in the FCL - after all, it isn't a visual component...

Michael.

Yes, this would be even more logical :-)

Michal Bukovjan