Recent

Author Topic: fpcup 3.1.1 Update  (Read 115365 times)

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #30 on: May 05, 2015, 07:22:43 pm »
Strange. No fpcup errors in your log. The logfile shows clearly:
Quote
[2015-05-05 18:27:56.206 Info] FPC: WARNING: found modified files.
C:\development\fpc\packages\fcl-db\src\sqlite\customsqliteds.pas
C:\development\fpc\packages\fcl-db\src\sqlite\sqlite3ds.pas
Diff with last revision stored in C:\development\fpc\REV30552.diff
FPC: reverting before updating.
FPC: reapplying local changes.

So, fpcup (svn) detects changed files. And reapplies the changes. All ok so far.
The two files have been changed back to trunk.
You should be able to check this.

Remaining problem: why are the original .o and .ppu still floating around.

I think it is, because fpcup detects no changes in fpc revision.
And therefor thinks no new compilation is needed.

This would mean that I have to add a new --force parameter, to force fpc to recompile !
I will have a look at it !!

totya

  • Hero Member
  • *****
  • Posts: 643
Re: fpcup 3.1.1 Update
« Reply #31 on: May 05, 2015, 08:00:12 pm »
Code: [Select]
fpcup --force --fpcURL="default" --keeplocalchanges="false" --reapplylocalchanges="true" --only="fpc,fpccrosswin32-64"

fcpup doesn't accept this parameter...

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #32 on: May 05, 2015, 08:24:15 pm »
Quote
This would mean that I have to add a new --force parameter
new = it is not yet there  ;)

I cannot reproduce your problem ! At my systems, recompiling works 100%. Also one same fpc revisions.

I did have a close look at your log. Look at the times !
Quote
[2015-05-05 18:26:17.286 Info] 2015.05.05. 18:26:17: fpcup fpcup001 (20150210) started.
[2015-05-05 18:27:56.206 Info] FPC: WARNING: found modified files.
[2015-05-05 18:32:27.813 Info] FPC: update succeeded.
[2015-05-05 18:36:05.280 Info] 2015.05.05. 18:36:05: fpcup finished.
Between patching and finish are 9 minutes.
So fpcup did compile fpc.
The only think I can think of is multiple fpc disturbing each other !

Sorry I cannot help you more.

totya

  • Hero Member
  • *****
  • Posts: 643
Re: fpcup 3.1.1 Update
« Reply #33 on: May 05, 2015, 08:27:58 pm »
Between patching and finish are 9 minutes.
So fpcup did compile fpc.
The only think I can think of is multiple fpc disturbing each other !

Sorry I cannot help you more.

Yes, compile from old source... okay, your solution doesn't work, but thanks your job!

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #34 on: May 05, 2015, 08:38:15 pm »
What patch binary do you have on your pc ?
This could be the problem.
Patch needs a manifest to elevate itself.

avra

  • Hero Member
  • *****
  • Posts: 2144
    • Additional info
Re: fpcup 3.1.1 Update
« Reply #35 on: May 06, 2015, 12:38:04 am »
Testing and reports are very welcome !
I will continue our PM conversation here since files can not be attached to PM, and all this would probably interest some other fpcup users...

Everything works again with latest fpcup. Tested in Win7 32bit VM. Lazpaint module does not hang the whole process any more and is properly built. SVN client download url is correct now and SvnURL modules work again even on a machine without any SVN client preinstalled. GitURL and HgURL work when proper clients are preinstalled (tested with TortoiseGit and TortoiseHg). GitURL will not work if during GIT for Windows installation default "Use Git from Git Bash only" is selected. Selecting "Use Git from the Windows Command Prompt" worked for me. This is info that does not exist in any fpcup documentation I could read so it should probably end up in a wiki page.

Mormot is default module in fpcup. I think it should not be default. Just let the user use it if he wants. That way if it goes wrong, fpcup with default settings will still be able to finish it's job.

Bgra now compiles without manually commenting the problematic line (trunk seams to be corrected), but anchordocking seams to have a problem in laz trunk (I think, since it works with laz 1.4). It compiles well but has a serious layout save/restore bug which completely kills usability. It is not a fpcup problem but it is worth mentioning for current users.

Again, attached BAT file TrunkAll downloads trunk fpc and trunk laz, while TrunkLaz BAT file downloads stable fpc (2.6.fixes) and trunk laz (with all modules). There is nothing windows specific in BAT files so they should be cross compatible. Of course, attached FPCUP.INI and MYSETTINGS.INI should be put into FPCUP.EXE directory. I have modified them and corrected errors where needed, so using them now allows downloading correctly all modules (anchordocking, bgracontrols, brookframework, codelibrarian, dcpcrypt, default, doceditor, ecc, fblib, fpcdocs, fpcup, fpspreadsheet, glscene, greyhound, helpfpc, helplazarus, indy, kzdesktop, lazarus_ccr, lazbuild, lazdatadesktop, lazpackager, lazpaint, lazres, leptonica, lhelp, ljgridutils, lnet, mormot, mupdf, nxpascal, OCRivist, pascalsane, patchwrangler, rx, simplegraph, suggestedpackages, synapsetrunk, tesseract, tiopf, USERIDE, vampyre, vtv and zeos). I have not yet tested installerlazwin module. I have extended lazarus_ccr module so now it downloads complete repo and installs these additional components: cmdbox, lazcolorpalette, fpspreadsheet, fpspreadsheet_visual, fpspreadsheetexport_visual, gradcontrols, jujiboutils, JvCoreLaz, JvNavigationPaneLaz, JvXPBarLaz, kcontrolslaz, lazbarcodes, longtimerpackage, tponguard, playwavepackage, poweredby, pack_powerpdf, richmemopackage, lazrichview, scrolltext, spktoolbarpackage, tdi, lazparadox, tvplanit, virtualtreeview_package, and zvdatetimectrls. Other packages are listed but commented for various reasons. More info about it can be read inside FPCUP.INI. I have corrected GitURL paths for these modules: brook, tiopf, lazpackager, ljgridutils, greyhound, lazmupdf, fblib and mormot. It works now for me, so check if it works for you. I have also corrected modules 18, 19, 22, 39, 40 and 41. Please take a look and apply if you agree with such changes. With tiopf we need to execute "git checkout tiopf2" from tiopf source dir. You will see my unsuccessful attempt to automate this in FPCUP.INI, so please take a look and see if you have a better idea which would work. So far it needs to be done manually.

My further steps would be to try to add new modules I proposed earlier (again time is the limit), and after that I would try to add CodeTyphon exclusive modules to fpcup. It would not be needed to download the whole 600MB CT archive since I have already found while monitoring CT updater with WireShark that just interesting files can be downloaded from these locations:
http://www.pilotlogic.com/codetyphon/current/src/typhon_src.7z (35MB with all CT components)
http://www.pilotlogic.com/codetyphon/current/src/CodeOcean.7z (optional 125MB with all CT examples)
Then I would have to find a way to unpack them (7zip is still not supported in fpcup), programmatically change pl_* required package references in code as I already do by hand, and install them. Everything automated. I would also make a special module called max that would include all other modules, and user should be able to easily install or update Lazarus with zillion components, libraries and frameworks with just a single fpcup command.

As a general idea, it would be good if we could parameterize module to be installable only on specific operating system and bitness. Something like AllowedOS=win32,lin32,lin64 or similar in FPCUP.INI definition of that module. Does something like that already exist?
« Last Edit: May 06, 2015, 01:00:15 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #36 on: May 06, 2015, 07:08:59 am »
THANK YOU !  :)

Main thing: certainly, the Wiki page has to be updated !!

I have to reply quick ... I am on holiday .. will come back to you in a few days.

1 question: the whole of lazarus ccr is now downloaded (if enabled), but many packages are not used. Would it perhaps be better to make every of  these packages a single module. To limit download bandwidth. Or is it a feature to have them all. I am open for every suggestion.
(a possibility: combine ini sections :
[lazarus-ccr]
kcontrols=1
...
[TrunkAll]
includesection=lazarus-ccr
ecc=1
...
)

Thanks again for your work.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4002
  • I like bugs.
Re: fpcup 3.1.1 Update
« Reply #37 on: May 06, 2015, 01:21:08 pm »
DonAlfredo, do you know about this mail thread ?
  http://lists.freepascal.org/pipermail/fpc-devel/2015-February/035378.html

I think you should inform the FPC developers if you are planning to maintain fpcup also in future. They also have a similar plan but it may take time because they already have enough packages and other duties. For that reason I don't think it would be maintained very well then. They might be happy if somebody else does it.

If you want, you could propose yourself as a maintainer and the GitHub location documented as the "official" place.

The worst case scenario is that FPC developers start to maintain fpcup without knowing about your doings. I don't believe anybody would benefit from that situation given the limited resources.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

avra

  • Hero Member
  • *****
  • Posts: 2144
    • Additional info
Re: fpcup 3.1.1 Update
« Reply #38 on: May 07, 2015, 12:52:10 am »
Main thing: certainly, the Wiki page has to be updated !!
This is a wiki reminder: Add howto for adding a new module to existing fpcup installation since it's not obvious. If there is no better way use once "--only=newmodulename" before new recompilation.

Quote
I have to reply quick ... I am on holiday .. will come back to you in a few days.
Please forget completely fpcup until you return and enjoy your holiday ;-)

Quote
1 question: the whole of lazarus ccr is now downloaded (if enabled), but many packages are not used. Would it perhaps be better to make every of  these packages a single module. To limit download bandwidth. Or is it a feature to have them all. I am open for every suggestion.
If there would be only lazarus-ccr then I could maybe vote to break it into single modules, however plan would be to have many, many new modules in the future. If we bring a "rule" to break each into sub modules, then we would not have hundreds but thousands of them. I would prefer something like having "FPCUPUSER.INI" that if exists, would have priority in search for modules. That way for example we could have default lazarus-ccr module options in "FPCUP.INI", but if the user has made "FPCUPUSER.INI" and it contains lazarus-ccr module FPCUP should take that one instead. Also, it would virtually eliminate a need to touch original "FPCUP.INI".

Quote
(a possibility: combine ini sections :
[lazarus-ccr]
kcontrols=1
...
[TrunkAll]
includesection=lazarus-ccr
ecc=1
...
That's a nice type saving and readability improvement feature. Since both TrunkAll and TrunkLaz have the same list of modules, I could use this feature to avoid double typing.
« Last Edit: May 07, 2015, 01:10:03 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #39 on: May 09, 2015, 10:46:21 pm »
I have made (most of the requested) changes for fpcup, and some other minor improvements.

Please test. Remarks very welcome as usual !

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #40 on: May 09, 2015, 10:51:21 pm »
@JuhaManninen
Maintaining fpcup is, at this moment, just a pleasure and a desire to not forget (the work of) BigChimp.
So, if fpc-core wants to take over / continue : perfectly fine.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4002
  • I like bugs.
Re: fpcup 3.1.1 Update
« Reply #41 on: May 12, 2015, 07:08:26 am »
@JuhaManninen
Maintaining fpcup is, at this moment, just a pleasure and a desire to not forget (the work of) BigChimp.
So, if fpc-core wants to take over / continue : perfectly fine.

Maybe you misunderstood my meaning. I don't want to stop you from maintaining it, I only want you to communicate your future plans about it.
See the mail thread I linked. There my interpretation was that you want to maintain it but Michael Thompson's interpretation was that you don't want to do it ... And it is still not clear from your last comment.

Please tell your plans preferably in fpc-devel mailing list. You can become the "official" maintainer if you want. Lack of communication can lead to duplicated effort when people don't know about each others' work, and is unfortunate for the users as well.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

JZS

  • Full Member
  • ***
  • Posts: 184
Re: fpcup 3.1.1 Update
« Reply #42 on: May 12, 2015, 10:42:23 am »
If by votes, I vote for DonAlfredo, to be the official maintainer of fpcup.

Thank you for keeping it alive, for BigChimp.

Regards,

PS: I already tried the updated fpcup successfully, on Win 8 32bit, runs without issues.
« Last Edit: May 12, 2015, 10:47:50 am by JZS »
I use recent stable release

avra

  • Hero Member
  • *****
  • Posts: 2144
    • Additional info
Re: fpcup 3.1.1 Update
« Reply #43 on: May 14, 2015, 11:15:35 am »
Huh, I had many problems with TrunkAll until I found the guilty ones. First, in suggestedpackages I had to comment editormacroscript, datetimectrls and industrial packages, since they were producing errors. Then I had to comment everything related to bgra, then zeos, cm630commons, lazmer and pascalscada since they were doing the same. And each time (even with last successful fpcup session) I got 2 x "ppc386.exe" has stopped working. Windows is checking for a solution to problem" messages. I have seen some other new modules that you have included in latest fpcup but I had no time for testing them. I have also tried "includesection" but it does not seam to work yet. Please let me know if/when you implement it.
I was also surprised that I had to comment modules helpfpc, helplazarus, lazbuild and USERIDE. Otherwise fpcup failed. Am I doing something wrong or something was changed lately?

For pascalscada to work, I will try your idea with one slight modification, and see if that works:
Code: [Select]
...
name=pascalscada
Requires=fpcup
Patch=$(fpcdir)/../extras/fpcup/componentpatches/$(name).diff
...

Having so much trouble, I had an irritating experience of fpcup sessions failing about 20-30 times, and each time because of one different module. Then seing if something can be done or commenting it and repeating the process. Very, very unfriendly, so I gave up a few times and had to spread this testing over several days. Instead of adding new modules as I wanted to, I was spending time on troubleshooting. Therefore I propose a switch that would allow continuing even with non-critical failures, and writing to errors.log a list of all errors. That way we could have much more chances for successful session, and comment all problematic modules in a single try (if we want to bother at all). I would also make this switch default one and ease everyone's experience with fpcup. What do you think? Can you please take a look? I hope that something like that would not be too hard and time consuming to implement.

I have attached workable TrunkAll with changes from above.
« Last Edit: May 14, 2015, 11:17:54 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1442
Re: fpcup 3.1.1 Update
« Reply #44 on: May 14, 2015, 02:57:24 pm »
Thanks for your feedback !
I think we would have to change our mindset about fpcup.

Bare fpcup will install fpc (and Lazarus) on all systems without much effort.
So it fulfills its primary goal.

The problem starts with the additional packages and modules:
versions (like trunk / stable)
os-systems (Win, OSX, ..)
cpu (arm, i386, ...)

Every external package has its limitations.

E.g. the problems you encounter with TrunkAll did not happen on my system. In fact, TrunkAll gave me a CodeTyphon like install with very many working packages on both Windows and OSX. Working 100%.

So, we have do the tedious job to work through the list of modules on all systems !
A lot of work.

My method at this moment:
perform a bare (no extra modules) install with fpcup : fpcup
install a needed module with fpcup : fpcup --only="indy"
install another needed module with fpcup : fpcup --only="bgracontrols"
install another needed module with fpcup : fpcup --only="ecc"
and so on .....
....

 

TinyPortal © 2005-2018