Discussion:
How to change default editor font *before* primary config ~/.lazarus is created?
(too old to reply)
Bernd
2012-10-15 13:37:43 UTC
Permalink
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?

--
William Oliveira Ferreira
2012-10-15 15:34:27 UTC
Permalink
I think the default font should be the same from the Window manager. On
Gnome is possible to set the default font for mono spaced text. Lazarus
should read that setting on first run...
--
________________________________
William de Oliveira Ferreira
Mattias Gaertner
2012-10-16 08:31:13 UTC
Permalink
I think the default font should be the same from the Window manager. On Gnome
is possible to set the default font for mono spaced text. Lazarus should read
that setting on first run...
Can you find out how to get that setting?
Then maybe it can be done.

Mattias

--
Bernd
2012-10-15 20:00:15 UTC
Permalink
I have filed a bug. There is something strange going on during IDE
startup that defies all logic:

http://bugs.freepascal.org/view.php?id=23128

--
Mattias Gaertner
2012-10-16 08:26:48 UTC
Permalink
Post by 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.
Are you reinventing the wheel or do you use the deb scripts that are used for sf
packages?
Post by Bernd
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.
Post by Bernd
Is this a bug? I think so!)
AFAIK it works.
Post by Bernd
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

--
Bernd
2012-10-16 10:39:10 UTC
Permalink
Post by 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)


~~~*~~~
Post by Mattias Gaertner
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.

--
Bernd
2012-10-16 10:50:20 UTC
Permalink
Post by 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;

--
Bernd
2012-10-16 12:16:48 UTC
Permalink
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 ----------
From: Bernd <***@gmail.com>
Date: 2012/10/16
Subject: Re: [Lazarus] How to change default editor font *before*
primary config ~/.lazarus is created?
Post by Bernd
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.
Post by Bernd
$(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)
Post by Bernd
# 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.
Post by Bernd
# 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
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.
Post by Bernd
# 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
yes, you are right, install would be better.
Post by Bernd
# 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.

--
Mattias Gaertner
2012-10-17 08:57:49 UTC
Permalink
[...]
Post by Bernd
Post by Bernd
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.
Post by Bernd
Post by Bernd
$(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.
Post by Bernd
Post by Bernd
# 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.
Post by Bernd
Post by Bernd
# 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
sudo make install
no, it cannot work.
You lost me here. How can something not work that just worked?
Post by Bernd
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?
Post by Bernd
Post by Bernd
# 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
yes, you are right, install would be better.
Post by Bernd
# 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

--
Bernd
2012-10-17 10:15:00 UTC
Permalink
Post by 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.

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.
Post by Mattias Gaertner
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.

--
Mattias Gaertner
2012-10-17 10:46:07 UTC
Permalink
Post by Bernd
Post by 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.
Post by Bernd
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.
Post by Mattias Gaertner
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
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/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
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/
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

--
Bernd
2012-10-17 12:38:37 UTC
Permalink
Post by 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!)

--
Bernd
2012-10-20 19:19:37 UTC
Permalink
Post by 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.

--
Bernd
2012-10-21 19:00:27 UTC
Permalink
Post by Bernd
I found another one while trying to package current trunk (svn39145)
components/synedit/design/languages
Patch:
http://bugs.freepascal.org/view.php?id=23186

Patching also some other Makefile problems.

--

Continue reading on narkive:
Search results for 'How to change default editor font *before* primary config ~/.lazarus is created?' (newsgroups and mailing lists)
61
replies
0.9.20 released
started 2006-11-08 14:52:42 UTC
lazarus@lists.lazarus.freepascal.org
73
replies
Haiku R1/alpha decisions
started 2008-08-07 21:07:24 UTC
haiku-development@freelists.org
Loading...