Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-10

How to change default editor font *before* primary config ~/.lazarus is created?

14 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Bernd

I'm making a new installer for Lazarus on Debian and Ubuntu because the existing ones in their repositories are just plain wrong and broken beyond repair. I got everything working smoothly now, the only remaining (minor) problem is to replace the default editor font "Courier New" with something more appropriate on a Linux desktop.

Unfortunately Lazarus is ignoring /etc/lazarus/editoroptions.xml (according to strace it is opening the file but its contents do not seem to have any effect on the default font or any other editor setting I have tried. Is this a bug? I think so!) Where would be the proper place to patch the Lazarus sources, I grepped the Lazarus sources for "Courier New" but the only place that came up and made sense in this context was synedit.pp but I doubt its a good idea to simply patch the default font for SynEdit itself, I would rather avoid to patch anything that could potentially be linked into a user's application compiled with Lazarus.

Where should I have a look to either fix this bug (ignoring secondary config file) or to properly patch the default font?

Reply by email

Mattias Gaertner
to Bernd: I'm making a new installer for Lazarus on Debian and Ubuntu because the existing ones in…

Bernd hat am 15. Oktober 2012 um 15:37 geschrieben:

I'm making a new installer for Lazarus on Debian and Ubuntu because the existing ones in their repositories are just plain wrong and broken beyond repair.

Are you reinventing the wheel or do you use the deb scripts that are used for sf packages?

Show quoted text 8 lines
I got everything working smoothly now, the only remaining (minor) problem is to replace the default editor font "Courier New" with something more appropriate on a Linux desktop. Unfortunately Lazarus is ignoring /etc/lazarus/editoroptions.xml (according to strace it is opening the file but its contents do not seem to have any effect on the default font or any other editor setting I have tried.

The /etc/lazarus/editoroptions.xml is only copied if there is no ~/.lazarus/editoroptions.xml.

Is this a bug? I think so!)

AFAIK it works.

Show quoted text 10 lines
Where would be the proper place to patch the Lazarus sources, I grepped the Lazarus sources for "Courier New" but the only place that came up and made sense in this context was synedit.pp but I doubt its a good idea to simply patch the default font for SynEdit itself, I would rather avoid to patch anything that could potentially be linked into a user's application compiled with Lazarus. Where should I have a look to either fix this bug (ignoring secondary config file) or to properly patch the default font?

Mattias

Reply by email

Bernd
to Mattias Gaertner: Bernd hat am 15. Oktober 2012 um 15:37 geschrieben: Are you reinventing the wheel or do…

2012/10/16 Mattias Gaertner :

Are you reinventing the wheel or do you use the deb scripts that are used for sf packages?

I studied these scripts for some inspiration but I cannot use them as they are for the ubuntu build servers. They are constructing a package from the outside (they are putting the files together and calling the dpkg tools explicitly) but the way it should work is to have the package build *itself* with its rules file. debuild will first look for the debian folder, changelog, control and rules already in place and then call the targets in debian/rules that will perform the build and installation process.

Ideally (in a perfect world where make install does a correct and complete intallation) the rues file (which itself is a makefile too) would just look like this:

override_dh_auto_clean:
make clean

override_dh_auto_build:
make bigide

override_dh_auto_install:
make install PREFIX=$(CURDIR)/debian/lazarus/usr

%:
dh $@

This (along with the metadata in the other debian files) would normally be all that is needed to debianize any piece of software. When uploaded to the build servers they will unzip, look for the debian folder and call the targets in debian/rules.

currently my rules file looks like this (its still quite simple, 70% of it are comments with my rants about shortcomings of make install):

#!/usr/bin/make -f

OPT="-g- -Xs"
ROOT = $(CURDIR)/debian/lazarus
ORIG = $(CURDIR)

override_dh_auto_clean:
$(MAKE) -C $(ORIG) cleanbigide distclean

	find $(ORIG) -name "*.a" -exec rm {} \;
	$(RM) $(ORIG)/lazarus
	$(RM) $(ORIG)/startlazarus
	$(RM) $(ORIG)/lazbuild
	$(RM) -r /tmp/lazarus

override_dh_auto_build:
$(MAKE) -C $(ORIG) bigide OPT=$(OPT)

override_dh_auto_install:
# we do not need to install any of the compiled units because # they are never used, they would be a waste of disk space. # everything will be compiled on demand into ~/.lazarus/lib/

	find $(ORIG) -name "*.ppu" -exec rm {} \;
	find $(ORIG) -name "*.o" -exec rm {} \;
	find $(ORIG) -name "*.a" -exec rm {} \;

# we cannot directly install into $(ROOT)/usr
# because lazarus make install is broken (copy into itself) # so we install into a temp dir outside of this tree # please fix this in lazarus makefile
$(MAKE) -C $(ORIG) install PREFIX=/tmp/lazarus/usr

# because of the above now need to move it where it belongs mkdir -p $(ROOT)
mv /tmp/lazarus/usr $(ROOT)/
$(RM) -r /tmp/lazarus

# install forgot to install desktop start menu item # please fix this in lazarus makefile
mkdir -p $(ROOT)/usr/share/applications
mkdir -p $(ROOT)/usr/share/pixmaps
cp $(ORIG)/install/lazarus.desktop $(ROOT)/usr/share/applications/ convert $(ORIG)/images/icons/aqua.ico[0] $(ROOT)/usr/share/pixmaps/lazarus.png

# install forgot to install mime-types file and icons # please fix this in lazarus makefile
mkdir -p $(ROOT)/usr/share/mime/packages
mkdir -p $(ROOT)/usr/share/icons/hicolor/48x48/mimetypes cp $(ORIG)/install/lazarus-mime.xml $(ROOT)/usr/share/mime/packages/lazarus.xml cp debian_other/mime_icons/* $(ROOT)/usr/share/icons/hicolor/48x48/mimetypes/

# install default config files
# please fix this in lazarus makefile
mkdir -p $(ROOT)/etc/lazarus
cp debian_other/etc/* $(ROOT)/etc/lazarus/

# remove all symlinks (entire /usr/bin), we let them create # automatically through the debian/links file
$(RM) -r $(ROOT)/usr/bin

# unneeded stuff left over in the install directory $(RM) -r $(ROOT)/usr/share/lazarus/install
$(RM) -r $(ROOT)/usr/share/lazarus/debian
$(RM) -r $(ROOT)/usr/share/lazarus/debian_other

# the following is INCOMPLETE and its only a dirty workaround! # create most probably needed unit directories for rebuilding ide # the ide - when building itself - will try to mkdir -p them # which would fail because of permissions but it will never actually # write anything into them (it will use ~/.lazarus/units/ instead) # we are perfectly happy if these directories exist and are empty. # Launchpad has only two architectures and Lazarus only two stable # widgetsets for Linux, so I am creating only those directories. # please fix this in lazarus makefile
mkdir -p $(ROOT)/usr/share/lazarus/units/i386-linux/gtk2 mkdir -p $(ROOT)/usr/share/lazarus/units/i386-linux/qt mkdir -p $(ROOT)/usr/share/lazarus/units/i386-linux/nogui mkdir -p $(ROOT)/usr/share/lazarus/units/x86_64-linux/gtk2 mkdir -p $(ROOT)/usr/share/lazarus/units/x86_64-linux/qt mkdir -p $(ROOT)/usr/share/lazarus/units/x86_64-linux/nogui

# probably a lot more stuff needs to be fixed,
# must care about it when I have more time...

override_dh_builddeb:
dh_builddeb -- -Zxz -z7

%:
dh $@

The main difference to other installers is that it will not install the compiled units at all, it will install only source code into /usr/share/lazarus, compiled units are not installed because they are automatically compiled on demand when the user compiles the first program.

This also brings us in perfect compliance with debian policy because /usr/share now only contains platform independent source code (I will also further modify it to install binaries directly into /usr/bin, no symlinks, not having any binary file in /usr/share/ at all and also no need for /usr/lib/.

The package could further be split into two:

* lazbuild binary and all source code (no dependencies on anything other than fpc)
* lazarus-ide (only the binary, dependency on gtk2)

~~~*~~~

The /etc/lazarus/editoroptions.xml is only copied if there is no ~/.lazarus/editoroptions.xml.

Yes it is copied, one can see this when halting execution in the constructor of TEditorOptions but when continuing to run some milliseconds later it is overwritten with an almost empty default file. Tested with 1.0.2 and 1.0.3 from yesterday. Either something else is accessing this file bypassing TEditorOptions or something even more obscure is going on inside TEditorOptions itself. See my bug report.

Reply by email

Bernd
to Bernd

2012/10/16 Bernd :

Yes it is copied, one can see this when halting execution in the constructor of TEditorOptions but when continuing to run some milliseconds later it is overwritten with an almost empty default file. Tested with 1.0.2 and 1.0.3 from yesterday.

I have tried to debug it last night to find the reason for this behavior until my eyes hurt, I could not find it. Then as a desperate workaround I patched main.pp right after the command line options are parsed and then it started working as expected. But this is *not a fix*, its only a dirty workaround:

--- ide/main.pp.orig	2012-10-15 23:22:20.000000000 +0200
+++ ide/main.pp	2012-10-15 23:32:02.000000000 +0200
@@ -1291,6 +1291,9 @@
   DebugLn('TMainIDE.ParseCmdLineOptions:');
   Debugln('  PrimaryConfigPath="',UTF8ToConsole(GetPrimaryConfigPath),'"');
   Debugln('  SecondaryConfigPath="',UTF8ToConsole(GetSecondaryConfigPath),'"');
+
+  DebugLn('work around bug: copy editor options template early');
+  LazConf.CopySecondaryConfigFile('editoroptions.xml');
 end;
 procedure TMainIDE.LoadGlobalOptions;

Reply by email

Bernd

Sorry, again the message went only to Mattias while I thought we were still talking on the mailinglist, It must be the gmail web interface that sometimes makes it easy to accidentally press the wrong reply button or the reply on the wrong copy of the message while gmail still makes it appear as if it were part of the original thread. Here again a copy (sorry for eventual duplicate)

---------- Forwarded message ----------

Earlier message 106 lines
From: Bernd Date: 2012/10/16 Subject: Re: [Lazarus] How to change default editor font *before* primary config ~/.lazarus is created? To: Mattias Gaertner 2012/10/16 Mattias Gaertner : >> OPT="-g- -Xs" > > Why? I'm still working on it on my local pc (with rather slow disk) and want fast compiles and small files. Also because I do not actually use the compiled units I am only interested in a stripped lazarus binary, for running on the build farm (which are much more powerful machines) I would even add -CX -XX here. >> override_dh_auto_clean: >> $(MAKE) -C $(ORIG) cleanbigide distclean >> find $(ORIG) -name "*.a" -exec rm {} \; >> $(RM) $(ORIG)/lazarus >> $(RM) $(ORIG)/startlazarus >> $(RM) $(ORIG)/lazbuild >> $(RM) -r /tmp/lazarus > > Better start with an svn export. This is again a convenience for me doing repeated builds on my local machine. On the build server the $(ORIG) folder will contain a freshly unzipped upstream tarball or for my nightly fixes on launchpad it will contain a fresh snapshot of the fixes branch (this is created newly every time by a bzr-builder recipe from a mirror of the lazarus fixes branch in the launchpad bzr repository). This could be created by a separate script when run locally (it may *not* happen inside rules because the build servers do not have access to anything other than what is contained in the source package when the build has started) >> # we do not need to install any of the compiled units because >> # they are never used, they would be a waste of disk space. >> # everything will be compiled on demand into ~/.lazarus/lib/ >> find $(ORIG) -name "*.ppu" -exec rm {} \; >> find $(ORIG) -name "*.o" -exec rm {} \; >> find $(ORIG) -name "*.a" -exec rm {} \; > > Maybe not a good idea: The compile takes a lot of time, on multi user systems > (e.g. student pools) you get duplicates, home can be on a network share (slow). This is a valid point. But is it really significant for most users or for typical users nowadays? At one point (when they change lazarus build options) it will compiled into ~/.lazarus/ anyways. And its really fast, even on my very old laptop and happens only for the very first time (and then only after options have changed but this would happen anyways). On the other hand all the above brings down my entire deb package to only 45MB and reduces installed size in /usr/share greatly. >> # we cannot directly install into $(ROOT)/usr >> # because lazarus make install is broken (copy into itself) >> # so we install into a temp dir outside of this tree >> # please fix this in lazarus makefile >> $(MAKE) -C $(ORIG) install PREFIX=/tmp/lazarus/usr > > This works here: > sudo make install no, it cannot work. The typical setup for package building is that $(ORIG) and $(CURDIR) are identical (debian folder is in the same directory as the top level makefile). Actually I made this distinction between $(ORIG) and $(CURDIR) only because I need to workaround it for my nightlies because of the existing debian folder (i complained about) i cannot merge upstream and my own packaging, so i nest entire upstream into a subdirectory but I do this only for the nightlies and this is a very ugly hack and I ultimately want to avoid it. Ideally and normally $(ORIG) and $(CURDIR) are identical. And when ./debian/lazarus/usr/ is a subfolder of ./ then the following cp -r . ./somewhere/ will fail with error about recurively copying a folder into a subdirectory of itself. It should instead copy only what it needs explicitly. >> # install forgot to install desktop start menu item >> # please fix this in lazarus makefile >> mkdir -p $(ROOT)/usr/share/applications >> mkdir -p $(ROOT)/usr/share/pixmaps >> cp $(ORIG)/install/lazarus.desktop $(ROOT)/usr/share/applications/ >> convert $(ORIG)/images/icons/aqua.ico[0] $(ROOT)/usr/share/pixmaps/lazarus.png > > Do not use 'cp'. Use 'install': yes, you are right, install would be better. >> # the following is INCOMPLETE and its only a dirty workaround! >> # create most probably needed unit directories for rebuilding ide >> # the ide - when building itself - will try to mkdir -p them > > ok mkdir -p unit output directory seems to happen though some autogenerated (by fpcmake) snippet of makefile code that is automatically in all fpcmake Makefiles, it will probably not be easy to remove it.

Reply by email

Mattias Gaertner
to Bernd

[...]

Show quoted text 11 lines
2012/10/16 Mattias Gaertner : >> OPT="-g- -Xs" > > Why? I'm still working on it on my local pc (with rather slow disk) and want fast compiles and small files. Also because I do not actually use the compiled units I am only interested in a stripped lazarus binary, for running on the build farm (which are much more powerful machines) I would even add -CX -XX here.

I thought this is a proposal for better standard debian packages. The normal Lazarus user needs debug.

Show quoted text 21 lines
>> override_dh_auto_clean: >> $(MAKE) -C $(ORIG) cleanbigide distclean >> find $(ORIG) -name "*.a" -exec rm {} \; >> $(RM) $(ORIG)/lazarus >> $(RM) $(ORIG)/startlazarus >> $(RM) $(ORIG)/lazbuild >> $(RM) -r /tmp/lazarus > > Better start with an svn export. This is again a convenience for me doing repeated builds on my local machine. On the build server the $(ORIG) folder will contain a freshly unzipped upstream tarball or for my nightly fixes on launchpad it will contain a fresh snapshot of the fixes branch (this is created newly every time by a bzr-builder recipe from a mirror of the lazarus fixes branch in the launchpad bzr repository). This could be created by a separate script when run locally (it may *not* happen inside rules because the build servers do not have access to anything other than what is contained in the source package when the build has started)

ok, so not for the standard debian packages.

Show quoted text 20 lines
>> # we do not need to install any of the compiled units because >> # they are never used, they would be a waste of disk space. >> # everything will be compiled on demand into ~/.lazarus/lib/ >> find $(ORIG) -name "*.ppu" -exec rm {} \; >> find $(ORIG) -name "*.o" -exec rm {} \; >> find $(ORIG) -name "*.a" -exec rm {} \; > > Maybe not a good idea: The compile takes a lot of time, on multi user > systems > (e.g. student pools) you get duplicates, home can be on a network share > (slow). This is a valid point. But is it really significant for most users or for typical users nowadays? At one point (when they change lazarus build options) it will compiled into ~/.lazarus/ anyways. And its really fast, even on my very old laptop and happens only for the very first time (and then only after options have changed but this would happen anyways). On the other hand all the above brings down my entire deb package to only 45MB and reduces installed size in /usr/share greatly.

True. But Lazarus and fpc easily need one or two GB, so 45MB is not that much. And it is some kind of show stopper if the IDE recompiles everything to install one package.
Of course the binary will be smaller and some users have slow internet. So it has pros and cons. I can live with it.

Show quoted text 10 lines
>> # we cannot directly install into $(ROOT)/usr >> # because lazarus make install is broken (copy into itself) >> # so we install into a temp dir outside of this tree >> # please fix this in lazarus makefile >> $(MAKE) -C $(ORIG) install PREFIX=/tmp/lazarus/usr > > This works here: > sudo make install no, it cannot work.

You lost me here. How can something not work that just worked?

Show quoted text 14 lines
The typical setup for package building is that $(ORIG) and $(CURDIR) are identical (debian folder is in the same directory as the top level makefile). Actually I made this distinction between $(ORIG) and $(CURDIR) only because I need to workaround it for my nightlies because of the existing debian folder (i complained about) i cannot merge upstream and my own packaging, so i nest entire upstream into a subdirectory but I do this only for the nightlies and this is a very ugly hack and I ultimately want to avoid it. Ideally and normally $(ORIG) and $(CURDIR) are identical. And when ./debian/lazarus/usr/ is a subfolder of ./ then the following cp -r . ./somewhere/ will fail with error about recurively copying a folder into a subdirectory of itself. It should instead copy only what it needs explicitly.

I'm not sure I can follow you here. How can I reproduce the bug?

Show quoted text 22 lines
>> # install forgot to install desktop start menu item >> # please fix this in lazarus makefile >> mkdir -p $(ROOT)/usr/share/applications >> mkdir -p $(ROOT)/usr/share/pixmaps >> cp $(ORIG)/install/lazarus.desktop $(ROOT)/usr/share/applications/ >> convert $(ORIG)/images/icons/aqua.ico[0] >> $(ROOT)/usr/share/pixmaps/lazarus.png > > Do not use 'cp'. Use 'install': yes, you are right, install would be better. >> # the following is INCOMPLETE and its only a dirty workaround! >> # create most probably needed unit directories for rebuilding ide >> # the ide - when building itself - will try to mkdir -p them > > ok mkdir -p unit output directory seems to happen though some autogenerated (by fpcmake) snippet of makefile code that is automatically in all fpcmake Makefiles, it will probably not be easy to remove it.

Don't try. Just create the output directories to make mkdir -p happy. They don't hurt.

Mattias

Reply by email

Bernd
to Mattias Gaertner

2012/10/17 Mattias Gaertner :

Show quoted text 5 lines
True. But Lazarus and fpc easily need one or two GB, so 45MB is not that much. And it is some kind of show stopper if the IDE recompiles everything to install one package. Of course the binary will be smaller and some users have slow internet. So it has pros and cons. I can live with it.

Yesterday after doing more rigorous attempts to remove *all* binaries from the install directory (so that contents of /usr/share/ becomes truly architecture independent which is a *must* and the very definition and purpose of /usr/share/) I noticed that this gives some more subtle problems, when restarting the IDE after successful rebuild of the IDE it will look for startlazarus in the lazarus folder (and not on the search path). Therefore I have for now decided to install the entire lazarus into /usr/lib/lazarus and leave the executables it is looking for where they are.

This would make it possible to leave also the compiled units in the lazarus folder again (but of course only makes sense if I don't compile them with custom options). In the end this is only a change of one line in the rues file and does not break other things and it is nice to know that it is at least possible to make such a stripped down installer that still provides a fully functional Lazarus.

I'm not sure I can follow you here. How can I reproduce the bug?

It is because of the typical directory layout when building a .deb package. I will try to explain. Consider this simple hello world directory layout after unzipping and preparing the source for package building immediately before the actual build is started:

hello-world-1.0/debian/changelog
hello-world-1.0/debian/control
hello-world-1.0/debian/rules
hello-world-1.0/Makefile
hello-world-1.0/hello.lpi
hello-world-1.0/hello.lpr

after "make all" it might look like this:

hello-world-1.0/debian/changelog
hello-world-1.0/debian/control
hello-world-1.0/debian/rules
hello-world-1.0/Makefile
hello-world-1.0/hello.lpi
hello-world-1.0/hello.lpr
hello-world-1.0/hello.ppu
hello-world-1.0/hello.o
hello-world-1.0/hello

now it will call "make install" with PREFIX set to a special path that it will later use to zip the installation contents. This PREFIX folder is a subdirectory of the debian folder!

Our example makefile (just for illustration purpose) would for example install into $(PREFIX)/lib/hello and also a symlink into $(PREFIX)/bin so after make install it should look like this:

hello-world-1.0/debian/hello-world/usr/lib/hello/hello hello-world-1.0/debian/hello-world/usr/bin/hello -> ../lib/hello/hello hello-world-1.0/debian/changelog
hello-world-1.0/debian/control
hello-world-1.0/debian/rules
hello-world-1.0/Makefile
hello-world-1.0/hello.lpi
hello-world-1.0/hello.lpr
hello-world-1.0/hello.ppu
hello-world-1.0/hello.o
hello-world-1.0/hello

then after make install has completed debhelper tools will zip everything below debian/hello-world/ and make it the data.tar.gz member of the .deb

the reason why "make install" of lazarus fails is that at one point it does a

cp -r . $(PREFIX)/share/lazarus/

and with prefix set to ./debian/lazarus/usr this will expand like that:

cp -r . ./debian/lazarus/usr/share/lazarus/

which would attempt to copy the entire folder (*including* the debian folder!) into a subdirectory of itself (into the debian folder) and this will fail with error, cp will refuse to do this, it will start copying a few files but then when it comes to copying the ./debian folder into ./debian/lazarus/usr/share/lazarus/ it will abort with error.

this can be avoided by either copying only the needed files explicitly. I worked around this by installing into a temp dir *outside* the current directory and then in a separate step moving it back into ./debian/lazarus/usr where debhelper tools will expect it to be and removing the debian directory (and other unwanted stuff) from the final install directory again.

Reply by email

Mattias Gaertner
to Bernd

Bernd hat am 17. Oktober 2012 um 12:15 geschrieben:

Show quoted text 19 lines
2012/10/17 Mattias Gaertner : > True. But Lazarus and fpc easily need one or two GB, so 45MB is not that > much. > And it is some kind of show stopper if the IDE recompiles everything to > install > one package. > Of course the binary will be smaller and some users have slow internet. > So it has pros and cons. I can live with it. Yesterday after doing more rigorous attempts to remove *all* binaries from the install directory (so that contents of /usr/share/ becomes truly architecture independent which is a *must* and the very definition and purpose of /usr/share/) I noticed that this gives some more subtle problems, when restarting the IDE after successful rebuild of the IDE it will look for startlazarus in the lazarus folder (and not on the search path). Therefore I have for now decided to install the entire lazarus into /usr/lib/lazarus and leave the executables it is looking for where they are.

Looking for startlazarus in the search path might find one of a different version. Then you can get very strange errors. So if possible I would avoid searching in path.

Show quoted text 78 lines
This would make it possible to leave also the compiled units in the lazarus folder again (but of course only makes sense if I don't compile them with custom options). In the end this is only a change of one line in the rues file and does not break other things and it is nice to know that it is at least possible to make such a stripped down installer that still provides a fully functional Lazarus. > I'm not sure I can follow you here. How can I reproduce the bug? It is because of the typical directory layout when building a .deb package. I will try to explain. Consider this simple hello world directory layout after unzipping and preparing the source for package building immediately before the actual build is started: hello-world-1.0/debian/changelog hello-world-1.0/debian/control hello-world-1.0/debian/rules hello-world-1.0/Makefile hello-world-1.0/hello.lpi hello-world-1.0/hello.lpr after "make all" it might look like this: hello-world-1.0/debian/changelog hello-world-1.0/debian/control hello-world-1.0/debian/rules hello-world-1.0/Makefile hello-world-1.0/hello.lpi hello-world-1.0/hello.lpr hello-world-1.0/hello.ppu hello-world-1.0/hello.o hello-world-1.0/hello now it will call "make install" with PREFIX set to a special path that it will later use to zip the installation contents. This PREFIX folder is a subdirectory of the debian folder! Our example makefile (just for illustration purpose) would for example install into $(PREFIX)/lib/hello and also a symlink into $(PREFIX)/bin so after make install it should look like this: hello-world-1.0/debian/hello-world/usr/lib/hello/hello hello-world-1.0/debian/hello-world/usr/bin/hello -> ../lib/hello/hello hello-world-1.0/debian/changelog hello-world-1.0/debian/control hello-world-1.0/debian/rules hello-world-1.0/Makefile hello-world-1.0/hello.lpi hello-world-1.0/hello.lpr hello-world-1.0/hello.ppu hello-world-1.0/hello.o hello-world-1.0/hello then after make install has completed debhelper tools will zip everything below debian/hello-world/ and make it the data.tar.gz member of the .deb the reason why "make install" of lazarus fails is that at one point it does a cp -r . $(PREFIX)/share/lazarus/ and with prefix set to ./debian/lazarus/usr this will expand like that: cp -r . ./debian/lazarus/usr/share/lazarus/ which would attempt to copy the entire folder (*including* the debian folder!) into a subdirectory of itself (into the debian folder) and this will fail with error, cp will refuse to do this, it will start copying a few files but then when it comes to copying the ./debian folder into ./debian/lazarus/usr/share/lazarus/ it will abort with error. this can be avoided by either copying only the needed files explicitly. I worked around this by installing into a temp dir *outside* the current directory and then in a separate step moving it back into ./debian/lazarus/usr where debhelper tools will expect it to be and removing the debian directory (and other unwanted stuff) from the final install directory again.

I did the explicit approach.

Mattias

Reply by email

Bernd
to Mattias Gaertner

2012/10/17 Mattias Gaertner :

Looking for startlazarus in the search path might find one of a different version. Then you can get very strange errors. So if possible I would avoid searching in path.

This should not be possible since the deb would have installed its own startlazarus symlink into /usr/bin

There is one more minor problem with startlazarus I noticed: If lazarus folder is /usr/share/lazarus and startlazarus and lazarus executables exist in lazarus folder and custom built lazarus is in ~/.lazarus/ then startlazarus will ask the user which lazarus to start (the system installed or the one in the config directory).

But when the entire lazarus folder is in /usr/lib/lazarus (exact same direcrory layout, only everything in /usr/lib instead of /usr/share then startlazarus will always immediately start the custom built lazarus in ~/.lazarus all the time without asking. This is not a big problem since this is what the user most likely wanted to do anyways and relatively easily circumvent by starting lazarus-ide (which points to /usr/lib/lazarus/lazarus) from the command line but I think (without looking at the code now) this means that there are still some hardcoded paths in startlazarus where to look for the natively installed lazarus (instead of using the lazarus dir setting and finding it in /usr/lib/lazarus)

Now if I make an (almost empty) folder /usr/share/lazarus and copy only the two binaries (startlazarus and lazarus) over to /usr/share/lazarus (but not making any config changes, just put copies of those two binaries there) then starting startlazarus (when started from within /usr/shar/lazarus) will again open the question dialog. (but the one in /usr/lib/lazarus will still not see it, it only works when started from within /usr/share/lazarus!)

Reply by email

Bernd
to Mattias Gaertner: [...] I thought this is a proposal for better standard debian packages. The normal…

2012/10/17 Mattias Gaertner :

Don't try. Just create the output directories to make mkdir -p happy. They don't hurt.

I found another one while trying to package current trunk (svn39145) to install into /usr/lib/lazarus, this one is in synedit:

components/synedit/design/languages

If the directory exists and is empty I can re-build the IDE, otherwise it will throw an error and fail.

Reply by email