Sign in Join

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

Mailing lists / fpc-pascal / 2012-02

FPCUp FPC/Lazarus installer/updater: first Linux/Windows version released

32 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

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

Reinier Olislagers

Hi all,

With the help of the people on the forums and the lists, I've completed the first version of FPCup, a tool that downloads FPC and Lazarus sources from SVN, compiles and installs them.

For Windows, it offers bare-metal install functionality: it downloads an SVN executable and the binutils (make, etc).

On Linux, you'll need an SVN client, bunzip2 and the binutils (make etc) installed before running the program.

For Linux and Windows, if a bootstrap compiler is not present, it will download it for you.

fpcup will compile and install FPC and Lazarus in directories of your choosing (default provided). It will (minimally) configure Lazarus with compiler path, FPC source path in a separate primary config path (default under home on Linux, under LocalAppSettings under Windows).

It will place a desktop shortcut (Windows) or shell script in your home folder (Linux) to the new Lazarus instance.

It is meant for side-by-side installs: it installs new versions of FPC/Lazarus that don't influence existing can be run without admin rights (on Linux at least, should work on Windows, too).

Fpcup can also be used to update the installation; it does an svn upgrade and a recompile.

Testing on Windows (more extensive, I use it daily), and Linux x85 and Linux x64 shows it works.

Additional testers and early adopters welcome ;)

Released under the LGPL with FPC linking exception, just like FPC.

Next steps:
- write a GUI
- complete OSX version
- check/implement cross compiling support (Windows x86=>x64)
- try to integrate offline help/CHM generation (e.g. out of fpcdocs SVN)
- other things that are on my Lazarus forum post which I can't reach because the server seems down for maintenance...
- suggestions welcome

It can be found here:
https://bitbucket.org/reiniero/fpcup/overview
Windows, Linux x86 and LInux x64 binaries provided

Regards,
Reinier

Ludo Brands
to Reinier Olislagers
Hi all,

....

- suggestions welcome

Very nice!

Suggestions: :)
- replace 'Debug:' with 'Progress:' or 'Info:'. The messages are useful :)
- show some progress when checking out sources. The wait can be very long.
- option to not install/update fpc or lazarus (fe. setting the corresponding dir or url to '')
- in side by side, it is still juggling with command line parameters. Would be nice if fpcup would leave the settings in a .conf or .ini in the install dirs and when running fpcup from that dir it would pick up these settings and re-use them. Running fpcup in that dir with new parameters would update the settings. Similar to svn: you only specify the svn url once and do just an 'update' from then on.
- (I hesitated to put this in the category "bugs") lazarus is configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying fpc.cfg to ~/fpc/compiler/ still fails because the compiler still picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler dir will only be picked up when there is no .fpc.cfg in the home directory nor a fpc.cfg in the current directory nor one in the path specified by PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg and warning the user would be nice. Solving the problem would be more difficult. If "side by side" would be limited to different version numbers/architectures (as opposed to different revisions of the same version/architecture) then a 'pkexec make install INSTALL_PREFIX="whatever found in /etc/fpc.cfg" ' would be a solution.

Ludo

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote
Very nice!

Thanks.

Suggestions: :) - replace 'Debug:' with 'Progress:' or 'Info:'. The messages are useful :)

Yep, basically left a debug build up. Did intend to trim the messages some. Done in currnet commit.

- show some progress when checking out sources. The wait can be very long.

Ok. I think I will need help on that one but will come back to the list...

- option to not install/update fpc or lazarus (fe. setting the corresponding dir or url to '')

Ok. Was thinking about allowing recompiles anyway with different compiler options, so adding options e.g. --fpcnoupdate or --laznoupdate could work as well.
Makes having a GUI more of a necessity/advantage...

Show quoted text 6 lines
- in side by side, it is still juggling with command line parameters. Would be nice if fpcup would leave the settings in a .conf or .ini in the install dirs and when running fpcup from that dir it would pick up these settings and re-use them. Running fpcup in that dir with new parameters would update the settings. Similar to svn: you only specify the svn url once and do just an 'update' from then on.

Yep, agreed. I had something this planned.
Still thinking about where to put the ini though. I'd prefer to put it with fpcup itself. Otherwise you'd have to specify the directories each time again.
Your thoughts?

Show quoted text 9 lines
- (I hesitated to put this in the category "bugs") lazarus is configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying fpc.cfg to ~/fpc/compiler/ still fails because the compiler still picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler dir will only be picked up when there is no .fpc.cfg in the home directory nor a fpc.cfg in the current directory nor one in the path specified by PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg and warning the user would be nice.

Agreed.
If I understand the FPC User's Guide correctly, one could use the -n option to tell fpc to ignore config files, then specify the one we want with @. The question is, can that be done with Lazarus - I suppose not... Would copying over the newly installed FPC compiler's fpc.cfg to the installed lazarus dir work?

If "side by side" would be limited to different version numbers/architectures (as opposed to different revisions of the same version/architecture) then a 'pkexec make install INSTALL_PREFIX="whatever found in /etc/fpc.cfg" ' would be a solution.

So that would basically be an upgrade of the existing systemwide compiler, right? At first glance, I think I'd be very hesitant to do that as it will conflict with the distro's package manager. Of course, we're all developers, so we can deal with any problems, right.... ;)

Thanks for the feedback,
Reinier

Ludo Brands
to Reinier Olislagers
Show quoted text 6 lines
> - option to not install/update fpc or lazarus (fe. setting the > corresponding dir or url to '') Ok. Was thinking about allowing recompiles anyway with different compiler options, so adding options e.g. --fpcnoupdate or --laznoupdate could work as well. Makes having a GUI more of a necessity/advantage...

Solving next point will help. Adding compiler options was my next suggestion ;)

Show quoted text 15 lines
> - in side by side, it is still juggling with command line parameters. > Would be nice if fpcup would leave the settings in a .conf or .ini in > the install dirs and when running fpcup from that dir it would pick up > these settings and re-use them. Running fpcup in that dir with new > parameters would update the settings. Similar to svn: you only specify > the svn url once and do just an 'update' from then on. Yep, agreed. I had something this planned. Still thinking about where to put the ini though. I'd prefer to put it with fpcup itself. Otherwise you'd have to specify the directories each time again. Your thoughts?

When storing the settings in fpcdir and lazdir you simply run fpcup from that dir. The same as when doing 'svn up' from a dir. svn simply looks for .svn in the current dir and loads its settings.
When you store it in the dir containing fpcup, you need a mechanism to select one of the different settings.

Show quoted text 20 lines
> - (I hesitated to put this in the category "bugs") lazarus is > configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 > installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch > 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying > fpc.cfg to ~/fpc/compiler/ still fails because the compiler still > picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler dir will only > be picked up when there is no .fpc.cfg in the home directory nor a > fpc.cfg in the current directory nor one in the path specified by > PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg > and warning the user would be nice. Agreed. If I understand the FPC User's Guide correctly, one could use the -n option to tell fpc to ignore config files, then specify the one we want with @. The question is, can that be done with Lazarus - I suppose not... Would copying over the newly installed FPC compiler's fpc.cfg to the installed lazarus dir work?

I tried the latter but it didn't work.

Show quoted text 10 lines
> If "side by side" would be limited to different version > numbers/architectures (as opposed to different revisions of the same > version/architecture) then a 'pkexec make install > INSTALL_PREFIX="whatever found in /etc/fpc.cfg" ' would be a solution. So that would basically be an upgrade of the existing systemwide compiler, right? At first glance, I think I'd be very hesitant to do that as it will conflict with the distro's package manager. Of course, we're all developers, so we can deal with any problems, right.... ;)

No, the system wide compiler isn't changed. /usr/bin/fpc still points to the old compiler. You simply re-use the /etc/fpc.cfg which has entries like -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget. A 'make install INSTALL_PREFIX=/usr/lib' will put the units in /usr/lib/fpc/2.6.1 (if 2.6.1 is the version made) and leave the system compiler alone (if that isn't 2.6.1 ...). I agree that some checks need to be made to make sure that versions are different and /etc/fpc.cfg is indeed using $fpcversion macros in the unit paths.

Thanks, Ludo

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 7 lines
>> - show some progress when checking out sources. The wait > can be very >> long. > Ok. I think I will need help on that one but will come back > to the list... Echoing the output from svn to the console would be enough. It will also show the revision you are at which is missing now.

FYI, revision info is in my svn unit, just not being passed to the user ATM ;)

Regards,
Reinier

Reinier Olislagers
to Ludo Brands: Solving next point will help. Adding compiler options was my next suggestion ;) When…
Ludo Brands wrote 21 lines
>> - (I hesitated to put this in the category "bugs") lazarus is >> configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 >> installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch >> 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying >> fpc.cfg to ~/fpc/compiler/ still fails because the compiler still >> picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler > dir will only >> be picked up when there is no .fpc.cfg in the home directory nor a >> fpc.cfg in the current directory nor one in the path specified by >> PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg >> and warning the user would be nice. > Agreed. > If I understand the FPC User's Guide correctly, one could use > the -n option to tell fpc to ignore config files, then > specify the one we want with @. The question is, can that be > done with Lazarus - I suppose not... Would copying over the > newly installed FPC compiler's fpc.cfg to the installed > lazarus dir work? > I tried the latter but it didn't work.

What about letting fpcup write another shell script for fpc e.g. something like:

#!/bin/sh
~/wherever/we/installed/fpc -n @~/wherever/we/installed/fpc.cfg $* which should instruct our fpc to ignore any other fpc.cfg, use our own, and get any other arguments passed to the script.

Then assign this script as the compiler in Lazarus?!?!

(I suppose this might not work as Lazarus might be looking for other files in the compiler path!??!)

Alternatively, your other suggestion would be doable but sounds like a lot of work as well ;)

Regards,
Reinier

Ludo Brands
to Reinier Olislagers
Show quoted text 11 lines
#!/bin/sh ~/wherever/we/installed/fpc -n @~/wherever/we/installed/fpc.cfg $* which should instruct our fpc to ignore any other fpc.cfg, use our own, and get any other arguments passed to the script. Then assign this script as the compiler in Lazarus?!?! (I suppose this might not work as Lazarus might be looking for other files in the compiler path!??!)

The script still picks up 2.4.4 but the idea is good. This works:

#!/bin/sh
~/wherever/we/installed/compiler/ppc386 -n @~/wherever/we/installed/fpc.cfg $*

It picks up the right compiler but there is still a problem though: fpc.cfg includes the units searchpath ~/wherever/we/installed/units/$fpctarget but make install INSTALL_PREFIX=blah installs in
blah/lib/fpc/$fpcversion/units/$fpctarget. Running 'fpcmkcfg -d basepath=~/wherever/we/installed/lib/fpc/2.6.1 ...' solves this. Unfortunately 'basepath=~/wherever/we/installed/lib/fpc/$fpcversion' doesn't work. Lazarus seems to be perfectly happy with the script (I installed it in the fpc/bin directory)

Alternatively, your other suggestion would be doable but sounds like a lot of work as well ;)

Your solution is much better once the paths are sorted out.

One other problem: the debugger is configured as gdb which is not working. Lazarus looks for a gdb in the current directory (whatever that is), not in the path. Using the output of 'which gdb' would be the easiest solution on linux to set up the default gdb.

Regarding side by side installations, wouldn't it be better to store the lazarus config in a subdir of the lazarus install? A fixed directory makes side by side installation of lazarus very difficult.

Ludo

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 21 lines
> #!/bin/sh > ~/wherever/we/installed/fpc -n > @~/wherever/we/installed/fpc.cfg $* which should instruct our > fpc to ignore any other fpc.cfg, use our own, and get any > other arguments passed to the script. > > Then assign this script as the compiler in Lazarus?!?! The script still picks up 2.4.4 but the idea is good. This works: #!/bin/sh ~/wherever/we/installed/compiler/ppc386 -n @~/wherever/we/installed/fpc.cfg $* It picks up the right compiler but there is still a problem though: fpc.cfg includes the units searchpath ~/wherever/we/installed/units/$fpctarget but make install INSTALL_PREFIX=blah installs in blah/lib/fpc/$fpcversion/units/$fpctarget. Running 'fpcmkcfg -d basepath=~/wherever/we/installed/lib/fpc/2.6.1 ...' solves this. Unfortunately 'basepath=~/wherever/we/installed/lib/fpc/$fpcversion' doesn't work. Lazarus seems to be perfectly happy with the script (I installed it in the fpc/bin directory)

Ok, I've added this to my todo list
http://lazarus.freepascal.org/index.php/topic,15919.0.html In the meantime, patches welcome :)

One other problem: the debugger is configured as gdb which is not working. Lazarus looks for a gdb in the current directory (whatever that is), not in the path. Using the output of 'which gdb' would be the easiest solution on linux to set up the default gdb.

Agreed, added to todo list. On Windows, I think the path where make.exe is installed should also give an installed gdb.

Regarding side by side installations, wouldn't it be better to store the lazarus config in a subdir of the lazarus install? A fixed directory makes side by side installation of lazarus very difficult.

You mean a --primary-config path underneath the lazarus application directory? Could be done in principle.

Then again, current fpcup does not have a fixed primary-config-path, merely a default one.

I intended to leave the fpc and lazarus svn directories alone as much as possible so a user could delete everything and do a new checkout whenever he wants without touching config files.

I realize storing fpcup config files (e.g. SVN urls, etc) in the lazarus and/or fpc svn dirs may not be desirable - if we follow that strategy.

An alternative could be to use an fpcup config file stored wherever config files are stored on the os (forgot the function in FPC). Then use a default profile and allow the user to add profiles (e.g. using --saveasprofile=bla).
User can invoke with --profile=bla.
This will allow the GUI to also easily retrieve a list of side-by-side installs...

Regards,
Reinier

Reinier Olislagers
to Ludo Brands: The script still picks up 2.4.4 but the idea is good. This works: #!/bin/sh…
Ludo Brands wrote
One other problem: the debugger is configured as gdb which is not working. Lazarus looks for a gdb in the current directory (whatever that is), not in the path. Using the output of 'which gdb' would be the easiest solution on linux to set up the default gdb.

Just committed running 'which' to get gdb path for Unix/Linux. Not yet tested (or compiled, TBH).

Mattias Gaertner
to Reinier Olislagers: What about letting fpcup write another shell script for fpc e.g. something like: #!/bin/sh

Reinier Olislagers hat am 11. Februar 2012 um
08:28 geschrieben:

Show quoted text 17 lines
On 10-2-2012 18:23, Ludo Brands wrote: >>> - (I hesitated to put this in the category "bugs") lazarus is >>> configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 >>> installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch >>> 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying >>> fpc.cfg to ~/fpc/compiler/ still fails because the compiler still >>> picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler >> dir will only >>> be picked up when there is no .fpc.cfg in the home directory nor a >>> fpc.cfg in the current directory nor one in the path specified by >>> PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg >>> and warning the user would be nice. >> Agreed. >> If I understand the FPC User's Guide correctly, one could use >> the -n option to tell fpc to ignore config files, then >> specify the one we want with @. The question is, can that be >> done with Lazarus

Project Options / Compiler Options / Other

- I suppose not...

Why do you think so?

Would copying over the > >> newly installed FPC compiler's fpc.cfg to the

installed

Show quoted text 13 lines
>> lazarus dir work? >> > > I tried the latter but it didn't work. What about letting fpcup write another shell script for fpc e.g. something like: #!/bin/sh ~/wherever/we/installed/fpc -n @~/wherever/we/installed/fpc.cfg $* which should instruct our fpc to ignore any other fpc.cfg, use our own, and get any other arguments passed to the script. Then assign this script as the compiler in Lazarus?!?!

No need.

> (I suppose this might not work as Lazarus might be looking for other files in the compiler path!??!)

Lazarus does neither read nor search the fpc.cfg. It asks the compiler.

Mattias

Ludo Brands
to Reinier Olislagers: Ok, I've added this to my todo list http://lazarus.freepascal.org/index.php/topic,15919.0.…
Show quoted text 16 lines
> It picks up the right compiler but there is still a problem though: > fpc.cfg includes the units searchpath > ~/wherever/we/installed/units/$fpctarget but make install > INSTALL_PREFIX=blah installs in > blah/lib/fpc/$fpcversion/units/$fpctarget. Running 'fpcmkcfg -d > basepath=~/wherever/we/installed/lib/fpc/2.6.1 ...' solves this. > Unfortunately 'basepath=~/wherever/we/installed/lib/fpc/$fpcversion' > doesn't work. Lazarus seems to be perfectly happy with the script (I > installed it in the fpc/bin directory) Ok, I've added this to my todo list http://lazarus.freepascal.org/index.php/topic,15919.0.html In the meantime, patches welcome :)

Patch for script, unit path (using INSTALL_UNITDIR make parameter) and gdb/make attached.

Ludo

Sven Barth
to Ludo Brands: The script still picks up 2.4.4 but the idea is good. This works: #!/bin/sh…
Ludo Brands wrote 18 lines
> #!/bin/sh > ~/wherever/we/installed/fpc -n > @~/wherever/we/installed/fpc.cfg $* which should instruct our > fpc to ignore any other fpc.cfg, use our own, and get any > other arguments passed to the script. > > Then assign this script as the compiler in Lazarus?!?! > > (I suppose this might not work as Lazarus might be looking > for other files in the compiler path!??!) > The script still picks up 2.4.4 but the idea is good. This works: #!/bin/sh ~/wherever/we/installed/compiler/ppc386 -n @~/wherever/we/installed/fpc.cfg $*

You can use the "-Xp" option to specify a path for FPC to search for the ppc* binaries.

E.g.

#!/bin/sh
~/whereever/we/installed/fpc -n @~/whereever/we/installed/fpc.cfg -Xp~/whereever/we/installed/compiler $*

Regards,
Sven

Reinier Olislagers
to Mattias Gaertner: Reinier Olislagers hat am 11. Februar 2012 um 08:28 geschrieben: Project Options /…
Mattias Gaertner wrote 21 lines
Reinier Olislagers hat am 11. Februar 2012 um 08:28 geschrieben: > On 10-2-2012 18:23, Ludo Brands wrote: > >>> - (I hesitated to put this in the category "bugs") lazarus is > >>> configured to use (default on ubuntu) ~/fpc/bin/fpc. I have 2.4.4 > >>> installed with a /etc/fpc.cfg and ~/fpc/bin/fpc will just launch > >>> 2.4.4. Changing the compiler to ~/fpc/compiler/ppc386 and copying > >>> fpc.cfg to ~/fpc/compiler/ still fails because the compiler still > >>> picks up /etc/fpc.cfg. AFAIK the fpc.cfg in the compiler > >> dir will only > >>> be picked up when there is no .fpc.cfg in the home directory nor a > >>> fpc.cfg in the current directory nor one in the path specified by > >>> PPC_CONFIG_PATH nor a /etc/fpc.cfg. Detecting a conflicting fpc.cfg > >>> and warning the user would be nice. > >> Agreed. > >> If I understand the FPC User's Guide correctly, one could use > >> the -n option to tell fpc to ignore config files, then > >> specify the one we want with @. The question is, can that be > >> done with Lazarus Project Options / Compiler Options / Other

Danke, Mattias...

The thing is, we would like to set that by default, and also, if possible, let lazbuild work with it...

I suppose we could write some default value for Project Options/Compiler Options/Other but that would lead to problems whenever the user opens projects from another computer or even his side-by-side Lazarus install...

Show quoted text 12 lines
> #!/bin/sh > ~/wherever/we/installed/fpc -n @~/wherever/we/installed/fpc.cfg $* > which should instruct our fpc to ignore any other fpc.cfg, use our own, > and get any other arguments passed to the script. > > Then assign this script as the compiler in Lazarus?!?! No need. > > (I suppose this might not work as Lazarus might be looking for other > files in the compiler path!??!) Lazarus does neither read nor search the fpc.cfg. It asks the compiler.

Correct. Calling our newly installed fpc will presumably show the same problems (e.g. loading /etc/fpc.cfg) if a system-wide fpc was already installed....

A shell script in e.g. the user's home directory seems like a valid solution, but I'm open to suggestions...

Regards,
Reinier

Ludo Brands
to Reinier Olislagers: Ok, I've added this to my todo list http://lazarus.freepascal.org/index.php/topic,15919.0.…
Show quoted text 10 lines
> Regarding side by side installations, wouldn't it be better to store > the lazarus config in a subdir of the lazarus install? A fixed > directory makes side by side installation of lazarus very difficult. You mean a --primary-config path underneath the lazarus application directory? Could be done in principle. Then again, current fpcup does not have a fixed primary-config-path, merely a default one.

Unless I overlooked something, the primary-config-path is pretty hardcoded now (XdgConfigHome/lazarusdevsettings). Adding a parameter for primary-config-path would solve a lot.

I intended to leave the fpc and lazarus svn directories alone as much as possible so a user could delete everything and do a new checkout whenever he wants without touching config files.

Lazarus config files are sometimes part of the problem when working with svn. Making an all clean start would preferably also mean removing the lazarus config files.

I realize storing fpcup config files (e.g. SVN urls, etc) in the lazarus and/or fpc svn dirs may not be desirable - if we follow that strategy.

Why not create a fpcup script or link alongside the launcher(s) that take the same parameters as the one use to create the launcher? Something like 'lazlinkname' and 'lazlinkname Update'.

Ludo

Show quoted text 13 lines
An alternative could be to use an fpcup config file stored wherever config files are stored on the os (forgot the function in FPC). Then use a default profile and allow the user to add profiles (e.g. using --saveasprofile=bla). User can invoke with --profile=bla. This will allow the GUI to also easily retrieve a list of side-by-side installs... Regards, Reinier _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 12 lines
>> Regarding side by side installations, wouldn't it be better > to store >> the lazarus config in a subdir of the lazarus install? A fixed >> directory makes side by side installation of lazarus very difficult. > You mean a --primary-config path underneath the lazarus > application directory? Could be done in principle. > > Then again, current fpcup does not have a fixed > primary-config-path, merely a default one. Unless I overlooked something, the primary-config-path is pretty hardcoded now (XdgConfigHome/lazarusdevsettings). Adding a parameter for primary-config-path would solve a lot.

Oops, yes, you're right; will do that.

Lazarus config files are sometimes part of the problem when working with svn. Making an all clean start would preferably also mean removing the lazarus config files.

True, I think you just about persuaded me ;)

Show quoted text 6 lines
> I realize storing fpcup config files (e.g. SVN urls, etc) in > the lazarus and/or fpc svn dirs may not be desirable - if we > follow that strategy. Why not create a fpcup script or link alongside the launcher(s) that take the same parameters as the one use to create the launcher? Something like 'lazlinkname' and 'lazlinkname Update'.

Mmm, don't get what you mean here. What do you mean by launcher and the parameters used to create the launcher?

Off working on making --primary-config-path configurable... and applying your patch...

Marco van de Voort
to Ludo Brands: Unless I overlooked something, the primary-config-path is pretty hardcoded now…

In our previous episode, Ludo Brands said:

Show quoted text 7 lines
> Then again, current fpcup does not have a fixed > primary-config-path, merely a default one. > Unless I overlooked something, the primary-config-path is pretty hardcoded now (XdgConfigHome/lazarusdevsettings). Adding a parameter for primary-config-path would solve a lot.

There is --primary-config-path= and --lazarus-dir=

the latter only with .30 iirc. I used these for stick installs, where driveletters could be different all the time.

Lazarus config files are sometimes part of the problem when working with svn. Making an all clean start would preferably also mean removing the lazarus config files.

Daily going through the config dialogues is not fun either.

Ludo Brands
to Reinier Olislagers: Oops, yes, you're right; will do that. True, I think you just about persuaded me ;) Mmm,…
Show quoted text 8 lines
> Why not create a fpcup script or link alongside the launcher(s) that > take the same parameters as the one use to create the launcher? Something like > 'lazlinkname' and 'lazlinkname Update'. Mmm, don't get what you mean here. What do you mean by launcher and the parameters used to create the launcher?

Sorry, I mean the shortcut on desktop or home dir. The parameters are the fpcup parameters used to do all the nice work and that finishes with the creation of the mentioned shortcut. So, the alternative to storing config parameters somewhere is the suggestion to not create one but 2 shortcuts. The first launches lazarus and the second launches fpcup with the same parameters that were used to create these links. Example: a side by side installation of lazarus fpc 2.6.1 and lazarus fpc 2.7.1 gives 4 shortcuts, lazarus2.6.1 , lazarus2.6.1(Update), lazarus2.7.1 and lazarus2.7.1(Update).

Ludo

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 19 lines
>> Why not create a fpcup script or link alongside the > launcher(s) that >> take the same parameters as the one use to create the > launcher? Something like >> 'lazlinkname' and 'lazlinkname Update'. > Mmm, don't get what you mean here. What do you mean by > launcher and the parameters used to create the launcher? > Sorry, I mean the shortcut on desktop or home dir. The parameters are the fpcup parameters used to do all the nice work and that finishes with the creation of the mentioned shortcut. So, the alternative to storing config parameters somewhere is the suggestion to not create one but 2 shortcuts. The first launches lazarus and the second launches fpcup with the same parameters that were used to create these links. Example: a side by side installation of lazarus fpc 2.6.1 and lazarus fpc 2.7.1 gives 4 shortcuts, lazarus2.6.1 , lazarus2.6.1(Update), lazarus2.7.1 and lazarus2.7.1(Update).

Oh, I see.
That would be possible and quite... orthogonal (isn't there a less stuffy word for this?) to any decisions on config files and where to store them...

First let me get your patch and the --primary-config-path stuff done ;)

Thanks,
Reinier

Reinier Olislagers
to Marco van de Voort: In our previous episode, Ludo Brands said: There is --primary-config-path= and…
Marco van de Voort wrote 13 lines
In our previous episode, Ludo Brands said: >> Then again, current fpcup does not have a fixed >> primary-config-path, merely a default one. >> > > Unless I overlooked something, the primary-config-path is pretty hardcoded > now (XdgConfigHome/lazarusdevsettings). Adding a parameter for > primary-config-path would solve a lot. There is --primary-config-path= and --lazarus-dir= the latter only with .30 iirc. I used these for stick installs, where driveletters could be different all the time.

Thanks. As far as I can tell fpcup has no problem starting lazarus with the proper Lazarus directory but I might be missing something obvious again (happens a lot the last couple of days).

Mmm, of course it could be useful when doing an install on a memory stick on Windows... yet another batch script to start lazarus I suppose ;)

Show quoted text 5 lines
> Lazarus config files are sometimes part of the problem when working with > svn. Making an all clean start would preferably also mean removing the > lazarus config files. Daily going through the config dialogues is not fun either.

Mmm yes, but doing an svn up+compile on the lazarus dir, which fpcup does, shouldn't touch a --primary-config-path subdirectory (e.g. <lazarusdir>/LazarusDevSettings)... right?

For now, I'll create a command line parameter --primary-config-path= that allows users to store the path wherever they wish and for now let it default to the situation it currently is (e.g. somewhere below ~ on Unix, somewhere below %localappdata% on Windows).

Ludo Brands
to Marco van de Voort: In our previous episode, Ludo Brands said: There is --primary-config-path= and…
Show quoted text 6 lines
> Lazarus config files are sometimes part of the problem when working > with svn. Making an all clean start would preferably also mean > removing the lazarus config files. Daily going through the config dialogues is not fun either.

This was the case where the complete directory structure is deleted. Tabula rasa: full svn checkout, new fpc.cfg.

Ludo

Reinier Olislagers
to Ludo Brands: Unless I overlooked something, the primary-config-path is pretty hardcoded now…
Ludo Brands wrote 13 lines
>> Regarding side by side installations, wouldn't it be better > to store >> the lazarus config in a subdir of the lazarus install? A fixed >> directory makes side by side installation of lazarus very difficult. > You mean a --primary-config path underneath the lazarus > application directory? Could be done in principle. > > Then again, current fpcup does not have a fixed > primary-config-path, merely a default one. Unless I overlooked something, the primary-config-path is pretty hardcoded now (XdgConfigHome/lazarusdevsettings). Adding a parameter for primary-config-path would solve a lot.

I just committed a version with configurable --primary-config-path parameter. If not specified or empty, the original behavious still applies (eg. somewher below %localappdata% on windows, somewhere below ~ on Unix).

Also committed your Unix unit= fix for FPC make, and fpc.sh launcher script creation. Thanks.

Have not compiled in or tested on Linux though.

Thanks,
Reinier

Rainer Stratmann
to Reinier Olislagers: With the help of the people on the forums and the lists, I've completed the first version…
Reinier Olislagers wrote 5 lines
Hi all, With the help of the people on the forums and the lists, I've completed the first version of FPCup, a tool that downloads FPC and Lazarus sources from SVN, compiles and installs them.

Sorry for not reading the whole thread.
But is it then also possible to povide a binary version of each (Linux) distro for easiest installing (just unzip the archive)? FPC and Lazarus in one sub directory?

Reinier Olislagers
to Rainer Stratmann
Rainer Stratmann wrote
Sorry for not reading the whole thread. But is it then also possible to povide a binary version of each (Linux) distro for easiest installing (just unzip the archive)? FPC and Lazarus in one sub directory?

fpcup downloads (or updates) and installs fpc+lazarus and compiles them+adds some shortcuts/shell scripts that start up the new Lazarus. Both the newly installed FPC and Lazarus could reside in the same directory or at least subdirectories eg:
~
\
trunk
|
+-Lazarus
+-fpc
You'd need to provide the suitable directories to fpcup in the command line (see fpcup --help). A GUI for all of this is in development.

While the point of the program is to provide developers with an up to date version of SVN trunk (or whichever SVN branch/tag you want to track), it does not install documentation etc at the moment, or provide for a binary install (without downloading sources from SVN), and I think the .deb and .rpm packages are more suitable for that.

However, the desired goal of the program is that you run it and just get a working SVN version of Lazarus and FPC.

I suggest you try it on your Linux distro and see what happens. It is designed to leave any existing Lazarus and FPC installs alone (unless, of course, the installation directories overlap; see fpcup --help for options)

If you encounter any bugs, I'd be happy to try and fix them.

Regards,
Reinier

stootch
to Reinier Olislagers: With the help of the people on the forums and the lists, I've completed the first version…

W dniu 2012-02-10 15:24, Reinier Olislagers pisze:

Testing on Windows (more extensive, I use it daily), and Linux x85 and Linux x64 shows it works.

(...)

It can be found here: https://bitbucket.org/reiniero/fpcup/overview Windows, Linux x86 and LInux x64 binaries provided

Looks like a fine tool, however I have to report problems with Linux 64bit version.
FPCUp downloaded yesterday did not make Lazarus:

Show quoted text 32 lines
Info: Checking out/updating Lazarus sources... Info: Lazarus: running make clean: Info: Calling: Info: make FPC=/home/stootch/fpc/bin/fpc --directory=/home/stootch/lazarus UPXPROG=echo COPYTREE=echo clean Info: Command returned non-zero ExitStatus: 2. Output: Info: make: Entering directory `/home/stootch/lazarus' Makefile:196: *** The Makefile doesn't support target can't-executed,, please run fpcmake first. Stop. make: Leaving directory `/home/stootch/lazarus' Info: Lazarus: running make all: Info: Calling: Info: make FPC=/home/stootch/fpc/bin/fpc.sh --directory=/home/stootch/lazarus UPXPROG=echo COPYTREE=echo all Info: Command returned non-zero ExitStatus: 2. Output: Info: make: Entering directory `/home/stootch/lazarus' Makefile:196: *** The Makefile doesn't support target i386-linux, please run fpcmake first. Stop. make: Leaving directory `/home/stootch/lazarus' Lazarus retrieval/compilation failed. Please check program output for details. Possible troubleshooting steps: - make sure there's a valid SVN executable in your path. - make sure the GNU binutils (make etc), windres, subversion client are installed e.g. on Debian/Ubuntu: aptitude install build-essential subversion You might want to try removing all local changes in your SVN repository with: - try removing all local changes in your SVN repository with: SVN revert recursive /home/stootch/lazarus/ FPCUp finished.

Today's version (thank you for --skipfpc) gives similar result, moreover though, it makes FPC and tries to make Lazarus as 32bit:

Show quoted text 18 lines
Info: Checking for FPC bootstrap compiler: /home/stootch/fpcbootstrap/i386-linux-ppc386-1 Info: Found valid FPC bootstrap compiler. Info: Checking out/updating FPC sources... Info: Running make clean for fpc: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc UPXPROG=echo COPYTREE=echo clean Info: Running make for FPC: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc UPXPROG=echo COPYTREE=echo all Info: Running make install for FPC: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc INSTALL_PREFIX=/home/stootch/fpc INSTALL_UNITDIR=/home/stootch/fpc/units/i386-linux UPXPROG=echo COPYTREE=echo install

I'm running fully updated:

uname -a Linux debian 2.6.26-2-amd64 #1 SMP Wed Sep 21 03:36:44 UTC 2011 x86_64 GNU/Linux

stootch

Unknown author
to stootch

Thanks, stootch, sorry it did not work.

You might try with a newer version; we have found and hopefully fixed some problems with lazarus make...

Thanks for the detailed problem report,

ReinierOn 13-02-12 21:15 stootch wrote:
W dniu 2012-02-10 15:24, Reinier Olislagers pisze:

Testing on Windows (more extensive, I use it daily), and Linux x85 and Linux x64 shows it works.

(...)

It can be found here: https://bitbucket.org/reiniero/fpcup/overview Windows, Linux x86 and LInux x64 binaries provided

Looks like a fine tool, however I have to report problems with Linux 64bit version.
FPCUp downloaded yesterday did not make Lazarus:

Show quoted text 32 lines
Info: Checking out/updating Lazarus sources... Info: Lazarus: running make clean: Info: Calling: Info: make FPC=/home/stootch/fpc/bin/fpc --directory=/home/stootch/lazarus UPXPROG=echo COPYTREE=echo clean Info: Command returned non-zero ExitStatus: 2. Output: Info: make: Entering directory `/home/stootch/lazarus' Makefile:196: *** The Makefile doesn't support target can't-executed,, please run fpcmake first. Stop. make: Leaving directory `/home/stootch/lazarus' Info: Lazarus: running make all: Info: Calling: Info: make FPC=/home/stootch/fpc/bin/fpc.sh --directory=/home/stootch/lazarus UPXPROG=echo COPYTREE=echo all Info: Command returned non-zero ExitStatus: 2. Output: Info: make: Entering directory `/home/stootch/lazarus' Makefile:196: *** The Makefile doesn't support target i386-linux, please run fpcmake first. Stop. make: Leaving directory `/home/stootch/lazarus' Lazarus retrieval/compilation failed. Please check program output for details. Possible troubleshooting steps: - make sure there's a valid SVN executable in your path. - make sure the GNU binutils (make etc), windres, subversion client are installed e.g. on Debian/Ubuntu: aptitude install build-essential subversion You might want to try removing all local changes in your SVN repository with: - try removing all local changes in your SVN repository with: SVN revert recursive /home/stootch/lazarus/ FPCUp finished.

Today's version (thank you for --skipfpc) gives similar result, moreover though, it makes FPC and tries to make Lazarus as 32bit:

Show quoted text 18 lines
Info: Checking for FPC bootstrap compiler: /home/stootch/fpcbootstrap/i386-linux-ppc386-1 Info: Found valid FPC bootstrap compiler. Info: Checking out/updating FPC sources... Info: Running make clean for fpc: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc UPXPROG=echo COPYTREE=echo clean Info: Running make for FPC: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc UPXPROG=echo COPYTREE=echo all Info: Running make install for FPC: Info: Calling: Info: make FPC=/home/stootch/fpcbootstrap/i386-linux-ppc386-1 --directory=/home/stootch/fpc INSTALL_PREFIX=/home/stootch/fpc INSTALL_UNITDIR=/home/stootch/fpc/units/i386-linux UPXPROG=echo COPYTREE=echo install

I'm running fully updated:

uname -a Linux debian 2.6.26-2-amd64 #1 SMP Wed Sep 21 03:36:44 UTC 2011 x86_64 GNU/Linux

stootch

stootch
to Unknown author

W dniu 2012-02-14 10:41, pisze:

You might try with a newer version; we have found and hopefully fixed some problems with lazarus make...

Um...

Show quoted text 5 lines
Info: make FPC=/home/stootch/fpc/bin/fpc.sh --directory=/home/stootch/lazarus FPCDIR=/home/stootch/fpc/ UPXPROG=echo COPYTREE=echo clean all Info: Error setting Lazarus config: ERangeError/Range check error Lazarus retrieval/compilation failed.

It does, however, compile Lazarus, so I can start it, and once setting compiler to fpc.sh and sources directory, actually run IDE and compile projects.

Thanks for the detailed problem report,

I'm glad I could have been helpful. I'm sure you'll be able to fix the above mentioned bug.

And here goes one little feature request from me. FPCUp is supposed to be used on regular basis, right? Then it would be desired to have a log of some kind showing which revision and when had been checked out, so one would always know where to revert if things go wrong with the compiler or - especially - Lazarus in SVN.

stootch

Reinier Olislagers
to stootch
stootch wrote 13 lines
W dniu 2012-02-14 10:41, pisze: > You might try with a newer version; we have found and hopefully fixed > some problems with lazarus make... Um... > Info: make FPC=/home/stootch/fpc/bin/fpc.sh > --directory=/home/stootch/lazarus FPCDIR=/home/stootch/fpc/ > UPXPROG=echo COPYTREE=echo clean all > Info: Error setting Lazarus config: ERangeError/Range check error > Lazarus retrieval/compilation failed. It does, however, compile Lazarus, so I can start it, and once setting compiler to fpc.sh and sources directory, actually run IDE and compile projects.

Interesting error..!! I'll look into it.

Show quoted text 5 lines
And here goes one little feature request from me. FPCUp is supposed to be used on regular basis, right? Then it would be desired to have a log of some kind showing which revision and when had been checked out, so one would always know where to revert if things go wrong with the compiler or - especially - Lazarus in SVN.

Very much agreed, added to to do list; for now probably going to focus on reporting existing revision and downloaded revision in the normal fpcup output...

We'll have to think about what verbosity level is required for the log anyway... perhaps only show more if there are problems... but that would probably be done after we've got most bugs and features sorted out.

Thanks,
Reinier

Reinier Olislagers
to stootch: W dniu 2012-02-14 10:41, pisze: Um... It does, however, compile Lazarus, so I can start…
stootch wrote 10 lines
W dniu 2012-02-14 10:41, pisze: > You might try with a newer version; we have found and hopefully > fixed some problems with lazarus make... Um... > Info: make FPC=/home/stootch/fpc/bin/fpc.sh > --directory=/home/stootch/lazarus FPCDIR=/home/stootch/fpc/ > UPXPROG=echo COPYTREE=echo clean all Info: Error setting Lazarus > config: ERangeError/Range check error Lazarus retrieval/compilation > failed.

Dzień dobry, Stootch!

Ok. The binary you used was probably from the morning of the 14th. Since then, fixes have been made to the "which" command wrapper, which probably fixes the problem.

Could you test again please?

If it doesn't work, could you run it and send the output of
1. fpcup --help | grep "compiled with" #version of tool
2. fpcup --help | grep "for CPU" #platform used
3. cd ~/lazarus #(or your custom lazarus directory) #Check system wide settings (look for
#FPC, FPC version, FPCDIR and UnitsDir:
make fpc_baseinfo | less

4. cd ~/lazarus #(or your custom lazarus directory) #this should pick up the proper unit path
#fpcdir and version from the fpcup-installed fpc version #Check (look for FPC, FPC version, FPCDIR and UnitsDir: make fpc_baseinfo FPC=~/<yourfpcdirectory>/bin/fpc.sh

I'm assuming you're running fpcup with default values (i.e. lazarus directory = ~/lazarus, fpc directory = ~/fpc); if not, please adjust accordingly

BTW, new Linux x64 binary reports SVN versions when updating. Ludo Brands is busy designing info+error log output...

Thanks a lot for helping,
Reinier

Ludo Brands
to Sven Barth: You can use the "-Xp" option to specify a path for FPC to search for the ppc* binaries.…
Show quoted text 11 lines
You can use the "-Xp" option to specify a path for FPC to search for the ppc* binaries. E.g. #!/bin/sh ~/whereever/we/installed/fpc -n @~/whereever/we/installed/fpc.cfg -Xp~/whereever/we/installed/compiler $*

Tried this and it seemed to work fine, for a while. A nasty side-effect is that the ~/whereever/we/installed/compiler dir comes first in looking for sources. Encountered the problem with a project that had a unit named tokens...

Ludo

Mattias Gaertner
to Ludo Brands
Show quoted text 16 lines
> > You can use the "-Xp" option to specify a path for FPC to > search for the > ppc* binaries. > > E.g. > > #!/bin/sh > ~/whereever/we/installed/fpc -n @~/whereever/we/installed/fpc.cfg > -Xp~/whereever/we/installed/compiler $* > Tried this and it seemed to work fine, for a while. A nasty side-effect is that the ~/whereever/we/installed/compiler dir comes first in looking for sources. Encountered the problem with a project that had a unit named tokens...

Yes. See Lazarus / View / IDE Internals / About FPC. The last path is always the one where the compiler is.

Mattias

Ludo Brands
to Mattias Gaertner
Show quoted text 20 lines
> > You can use the "-Xp" option to specify a path for FPC to > > search for the > > ppc* binaries. > > > > E.g. > > > > #!/bin/sh > > ~/whereever/we/installed/fpc -n @~/whereever/we/installed/fpc.cfg > > -Xp~/whereever/we/installed/compiler $* > > > > Tried this and it seemed to work fine, for a while. A nasty > side-effect is that the ~/whereever/we/installed/compiler dir comes > first in looking for sources. Encountered the problem with a project > that had a unit named tokens... Yes. See Lazarus / View / IDE Internals / About FPC. The last path is always the one where the compiler is.

Looking at the fpc sources, I had already figured out that -Xp wasn't directly responsible and concluded that the compiler path was what caused the problem.

The last path in a long list of unitpaths that contain only .o,.a and .ppu makes it still the first path containing sources...

What is the rationale behind adding the compiler path to the search path for units and sources?

Ludo