minimum build environment for a GUI application

[robert rozee]

generally speaking, to build a LINUX GUI application from scratch one would install three packages, for FPC 3.6 this would be FPC-LAZ, FPC-SRC and Lazarus-Project, totaling around 220mb all up.

the above gives you a complete development environment, including a GUI IDE. this is not what i want.

my question is: what is the bare minimum from which one can run lazbuild project1.lpi from a terminal window and create a runnable binary without further manual intervention? no GUI, no means of editing any errors in your project's source code. i'm talking about a directory structure in the user's home directory containing the FPC compiler and (as far as is possible) just the source code to the various libraries, etc used to build project1.

the time taken to build is unimportant, so there should be no need for pre-built units to be included. it is perfectly acceptable that a build may generate tonnes of onscreen messages and take 10 or 15 minutes to complete. after project1 has been built, the directory structure containing FPC etc will be deleted.

can anyone offer some estimates? possibly even suggest how to go about creating such a setup? my goal is a means to create an installer for a user application written using lazarus that builds the user application on the user's local machine.


cheers,
rob   :-)

[dbannon]

Sadly Robert, its about the same. Sure, you don't need the lazarus executable but you do need all the LCL stuff. The source for the lazarus executable is not a very big part of the whole package !

If you build a non-gui app, (or FV app) different answer, all you need is FPC. And be careful not to call any of those familiar LCL non gui functions.

Davo 

[dsiders]

generally speaking, to build a LINUX GUI application from scratch one would install three packages, for FPC 3.6 this would be FPC-LAZ, FPC-SRC and Lazarus-Project, totaling around 220mb all up.

the above gives you a complete development environment, including a GUI IDE. this is not what i want.

my question is: what is the bare minimum from which one can run lazbuild project1.lpi from a terminal window and create a runnable binary without further manual intervention? no GUI, no means of editing any errors in your project's source code. i'm talking about a directory structure in the user's home directory containing the FPC compiler and (as far as is possible) just the source code to the various libraries, etc used to build project1.

the time taken to build is unimportant, so there should be no need for pre-built units to be included. it is perfectly acceptable that a build may generate tonnes of onscreen messages and take 10 or 15 minutes to complete. after project1 has been built, the directory structure containing FPC etc will be deleted.

can anyone offer some estimates? possibly even suggest how to go about creating such a setup? my goal is a means to create an installer for a user application written using lazarus that builds the user application on the user's local machine.


cheers,
rob   :-)

If you want to use lazbuild, that requires all three.

FPC has an fpcmake utility that can build your non-gui code... but that requires a working make file. And that's voodoo in its own right.

[JuhaManninen]

You can leave out Lazarus IDE binary + its plugin packages in the source tree, and example projects etc.
You need sources for LCL and the packages it depends on.

When built, LazBuild itself needs LCL and all the IDE's code dealing with projects and packages. Its dependencies are not optimal. It uses a "NoGUI" widgetset hack.

Actually you could leave out LCL's widgetsets which are not used, but then how useful would that be? Their sources don't occupy much space especially when compressed (ZIP maybe) for transfer.

[marcov]

the time taken to build is unimportant, so there should be no need for pre-built units to be included.

If you work with pre-built files, you can trim both the pre-built files and the sources. Generated FPC or Lazarus *.ppu/*.o mostly don't depend on the distribution.  If you require the full build to work, you might need them all, and need the space (for the generated files) anyway. As Juha says, lazbuild mostly requires project files for package dependencies, but not necessarily everything.

There is a small risk though, if the timestamps get messed up during transfer and pack/depack, this can lead to problems with prebuilds.

For a magnitude feel: On a Ryzen 5 5600g, an older machine, both FPC and Lazarus each compile in about 1m on *nix, and about 1:30 on windows, so that is 2-3m overall. I tested a Ryzen 7700 at work, and then it drops to around a minute for FPC, even on windows (didn't test lazarus).

[Scoops]

You are looking for a way to build a Lazarus project without Lazarus ?

https://wiki.freepascal.org/Using_the_LCL_without_Lazarus

Maybe you want something like this, i havnt actually tried.

[robert rozee]

You are looking for a way to build a Lazarus project without Lazarus ?

https://wiki.freepascal.org/Using_the_LCL_without_Lazarus

Maybe you want something like this, i havnt actually tried.

that is exactly what i am after      in particular, quoting the above wiki page:
"You may develop an application and distribute its sources. Some people will just want to build it, not develop it. Therefore, they should not be required to install the whole Lazarus development environment - it should be enough to only install the required libraries."

for various reasons i find it is becoming 'difficult' to just distribute a Linux ELF binary of a program created using Lazarus, increasingly i'm coming across cases where an ELF binary will not run for the end user due to minor niggling system differences. yet even though minor these are still differences that the end user is not sensibly able to rectify themselves. for this reason i'm looking at ways of creating a .DEB package that contains (1) the source code of my program, along with (2) sufficient parts of FPC and the LCL for the .DEB package to create a working 'temporary' build environment and then use this to build my program - after which the temporary build environment is then deleted.

i'm sure there must be others who have done this before! ideally i want the FPC compiler's binary to be the only executable contained in the .DEB package, with everything else therein consisting of just (highly compressable) source code that can be built into object files, used just the once, then deleted after an ELF binary of my application has been built.

does this sound reasonable?


cheers,
rob   :-)

[dbannon]

....
for various reasons i find it is becoming 'difficult' to just distribute a Linux ELF binary of a program created using Lazarus, increasingly i'm coming across cases where an ELF binary will not run for the end user due to minor niggling system differences.

Thats rather disturbing. I distribute my app as pre-made binaries and have not had any reports of such 'niggles'. Could you be more specific ?   
 

i'm sure there must be others who have done this before! ideally i want the FPC compiler's binary to be the only executable contained in the .DEB package, with everything else therein consisting of just (highly compressable) source code that can be built into object files, used just the once, then deleted after an ELF binary of my application has been built.

I'd think a deb source package might be a better approach. In that package you can specify the build process dependencies, ie FPC and Lazarus. Maybe you could also provide a bash script that looks at the deb source package, installs the dependencies, builds the app and then, still using apt or rpm (etc) removes the headline dependencies. But honestly, I really don't think this should be necessary.

[robert rozee]

That's rather disturbing. I distribute my app as pre-made binaries and have not had any reports of such 'niggles'. Could you be more specific?

lets start with the glibc2.34 issue that means not even the lazarus 4.0 IDE can run on many linux machines out in the wild:
https://forum.lazarus.freepascal.org/index.php/topic,71050.msg553991.html#msg553991
the cure, in that case, is running sudo make bigide from within the 4.0.0 directory.

then there is talk of GTK2 being removed from distros:
https://forum.lazarus.freepascal.org/index.php/topic,72724.msg570777.html#msg570777
in which case Lazarus GUI applications will need to be made runnable under both GTK2 and GTK3 - a task that i can see as being only practical by doing the actual ELF binary build on the end user's computer.

and not to forget the instance by many of our most active forum members that Lazarus (in the context of Linux) is strictly "write once, compile anywhere", NOT "compile once, run [under Linux] anywhere",
https://forum.lazarus.freepascal.org/index.php/topic,67629.msg521013.html#msg521013
this philosophy stated by MarkMLl in the above link, but repeated by many others in numerous forum postings. any discussions on the subject invariably end up with those "most active forum members" insisting that, for any Lazarus application that is going to be used on Linux, the end user must download the full Lazarus and FPC packages and then compile the application they want to use from source.


these are all issues (particularly regarding GLIBC) that i have been prattling on about for years, with nearly zero traction achieved. Michael Van Canneyt even took an interest a few yeas back, by as far as i can tell got nowhere with the other core developers. as far as i can determine, the only way forward is creating a 'lightweight' build environment as outlined in the link posted by Scoops in reply #5. the question is - how lightweight can we get?

I'd think a deb source package might be a better approach. In that package you can specify the build process dependencies, ie FPC and Lazarus. Maybe you could also provide a bash script that looks at the deb source package, installs the dependencies, builds the app and then, still using apt or rpm (etc) removes the headline dependencies. But honestly, I really don't think this should be necessary.

pulling in 220mb of dependencies just to build a single 4mb ELF binary is ridiculous. it is almost as insane as creating a SNAP package. surely we can do better than this?! or should we be using a different language?


cheers,
rob   :-)

[Fred vS]

Hi Rob.

You might want to take a look at the excellent Makefile that Alexander created for his Gork project.

The main Makefile:
https://codeberg.org/Alexander2024/gorg64/src/branch/main/Makefile

who call this:
https://codeberg.org/Alexander2024/gorg64/src/branch/main/src/Makefile

It solves your problems with glibc and creates deb and rpm packages.

(Okay, it's an MSEgui project, but the script can easily be adapted for LCL.  )

[marcov]

pulling in 220mb of dependencies just to build a single 4mb ELF binary is ridiculous. it is almost as insane as creating a SNAP package. surely we can do better than this?! or should we be using a different language?

IMHO it is too much trouble to get a binary that somewhat work, and then still risk that symlinks or other things are missing due to the more minor differences.

Simple create 3 or 4 VMs for the main target+version, and generate 4 x that 4 MB binary. No fuzz, no drama. At least that is what I did when I still had to distribute Linux binaries.

[Fred vS]

Simple create 3 or 4 VMs for the main target+version, and generate 4 x that 4 MB binary. No fuzz, no drama. At least that is what I did when I still had to distribute Linux binaries.

Or simply use this solution for your releases.

Okay, okay, I'm out. 

Peace and happiness to all.

Fre;D