Someone wrote me regarding Lazarus and asked:

"Can you please add auto update to the project? So I can auto update lazarus, freepascal without having to download 150mb each time?"

I wrote back telling the person I'd ask for feedback on the mailings lists. My questions is has anyone tackled this sort of feature for Lazarus and Free Pascal yet and if so what sort progress had you made or problems you had encountered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150413/311a230d/attachment.html>

Anthony Walter wrote

Someone wrote me regarding Lazarus and asked: "Can you please add auto update to the project? So I can auto update lazarus, freepascal without having to download 150mb each time?"

What is "auto update" other than downloading 150Mb and running the installer ?

Michael.

Are searching for something like fpcup ? It works with SVN and download only the changed code for Lazarus and fpc.

See http://wiki.lazarus.freepascal.org/fpcup

Regards,
Andi

Sorry for the confusion, the original question poster was referring to packages like the one I maintain at http://www.getlazarus.org/setup

The same request could be applied to the lazarus-ide.org direct downloads located here as well http://www.lazarus-ide.org/index.php?page=downloads

Or any other place which serves binary copies of FPC/Lazarus -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150413/9fea9955/attachment.html>

OK.

That still does not answer my question:

What is an 'auto update' feature supposed to do other than download a new release (possibly in the background) and start the installer ?

Do you need additional features: a diff kind of update, smaller download, recompile IDE with previously installed packages... whatever ?

Michael.

Michael Van Canneyt wrote

Do you need additional features: a diff kind of update,

My bet's primarily on this one.

smaller download, recompile IDE with previously installed packages... whatever ?

the latter being nice touches but dependent on the first too.

Probably doable IFF one wants to, or can, run on SVN/GIT releases
and rebuild by themselves;

how would one do binary diff updates in packaged world anyway...?

Michael.

el es

Lukasz Sokol wrote

Probably doable IFF one wants to, or can, run on SVN/GIT releases and rebuild by themselves;

I would (and already do) go with this option. It would also download the least about.

I'm pretty sure with 15 minutes to spare, somebody could write a Lazarus add-on (package) that registers a new "Get Updates" menu item in say the Help menu, which triggers a 'git stash; git pull; git stash pop' and then finally triggers the IDE to rebuild.

Regards,
- Graeme -

Michael Van Canneyt wrote

What is "auto update"

Yup, I'm assuming it is like that damn annoying thing under Mac OS X which you simply cannot disable for any installed applications or the OS. ;-)

Regards,
- Graeme -

Lukasz Sokol wrote

On 13/04/15 14:28, Michael Van Canneyt wrote: > Do you need additional features: a diff kind of update, My bet's primarily on this one.

Well then the question is, is the request for
- an AUTO update (same download, just the IDE checks for it)
- an UPDATE installer, that reduces the download size.

Of course ideally both.

IMHO the rebuild with your packages should not be part of the installer, but be done when you run the IDE. Same as we have the setup screen,the IDE could probably detect that the configured packages are no longer installed, and ask.

As for the installer size, their are many options. The problem is manpower. Such installers have to be build in order to be provided, and someone has to do this on every release.

Speaking of the windows installer (I do not know the others) It be possible to build an Lazarus only, no fpc, if you already have fpc in the correct version from the last install. But it needs to be build each time. And it will add work on support, if people try to use it with an older fpc,
It would also be possible to just install tho Lazarus sources, no ppu included, and then build them locally (more time to install, less download).

There are many possible variations. But they all will take time for building and testing on every release.

2015-04-13 16:28 GMT+02:00 Martin Frb :

IMHO this features are only a needless complexity. Both for Lazarus and FPC, SVN or Git do the work in a excellent way for a good programmer (i suppose Lazarus and FPC users are programmers). I'm an hobbist programmer (very poor for the truth) but I've no problems to update via SVN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150413/911a4df3/attachment-0001.html>

This is not so difficult.

IMHO the problem is primarily: what happens if it goes wrong. i.e. the compile fails somewhere halfway the LCL.

The IDE will continue to function, but you won't be able to compile any apps.

Also, doing this requires a checkout. This will increase diskspace etc. Lots of pitfalls.

Michael.

Il 13/04/2015 17:21, Salvatore Coppola ha scritto:

+1

Giuliano

Michael Van Canneyt wrote

IMHO the problem is primarily: what happens if it goes wrong.

Not sure about SubVersion (too too familiar with it any more, but the solution is pretty simple when using the Git mirrors. On a failure, revert to last used commit (SHA1).

i.e. the compile fails somewhere halfway the LCL. The IDE will continue to function, but you won't be able to compile any apps.

Giving the problem 15 seconds of my time (a better solution could probably be realised with more thought)... Instead of a "check for updates" which does everything, make it a dialog which tracks the last used commit (SHA1 value). So if anything goes wrong like you described, you can always go back into that dialog and select the "revert to previous commit", and you are back in action. ;-)

Also, doing this requires a checkout. This will increase diskspace etc.

Probably with SubVersion yes, but not a problem with Git. Git has the full history locally and you can switch to any commit in that history in an instant. Git previously noted, a git checkout with full history is still smaller than a single commit SVN checkout (which duplicates everything in the .svn directories). [this is how SVN used to work]

Summary of workflow using the Git mirror:

(dialog takes not of current SHA1 commit value)
git stash // save local changes you might have made git fetch
git stash pop // reapply your local changes (maybe this should be optional)
(trigger the IDE recompile)
... compilation failure detected...
(click that revert button)
git checkout <SHA1> // git resets back to the last good commit

A basic working package of this is still possible 15-30 minutes, even with the extra step.

Regards,
- Graeme -

If FP/Lazarus had dynamic binary packages, the packages (like laz-core, etc.) could be the only ones downloaded, and the user will benefit from already compiled packages and not worrying about if it's going to compile or not.. But of course the binary packages always runs into the usual problems: It would have to be sorted on the server by OS/Widget-Set, like Linux32+GTK+QT+Etc, Linux64+GTK+QT, Win32+Native+QT, Win64+Native+QT, etc. Everytime there is a new release server-side it would have to trigger a build of all of these.. The workaround for that could be just defaulting to some Widget-Sets, like GTK2 for Linux, and Native for Windows, etc. And if the user wants a different Widget-Set they can use the Source and compile their own.

But of course this is assuming dynamic binary packages existed in FP. ;)

- Dennis

If FP/Lazarus had dynamic binary packages, the packages (like laz-core, etc.) could be the only ones downloaded, and the user will benefit from already compiled packages and not worrying about if it's going to compile or not.. But of course the binary packages always runs into the usual problems: It would have to be sorted on the server by OS/Widget-Set, like Linux32+GTK+QT+Etc, Linux64+GTK+QT, Win32+Native+QT, Win64+Native+QT, etc. Everytime there is a new release server-side it would have to trigger a build of all of these.. The workaround for that could be just defaulting to some Widget-Sets, like GTK2 for Linux, and Native for Windows, etc. And if the user wants a different Widget-Set they can use the Source and compile their own.

But of course this is assuming dynamic binary packages existed in FP. ;)

- Dennis