Compilation info about FreeBSD and Raspberry

[fredvs]

Hello.

In readme.md there is:

... the program has been compiled on Windows, Linux and MacOS X.

Nice but there is also FreeBSD and Raspberry Pi!

;-)

[circular17]

Ok ok

[circular17]

Will you do a version for those as well for LazPaint 6.4.1 (version in the upstream folder)?

[circular17]

I am preparing the script to make the Deb package.

[fredvs]

Will you do a version for those as well for LazPaint 6.4.1 (version in the upstream folder)?

With pleasure!

Hum, I have allowed myself to answer these false accusations: here

(And maybe, if you read all the posts, you will understand why I was not too hot to install Lazarus on Rpi and prefer to compile LazPaint via ideU).

[circular17]

Will you do a version for those as well for LazPaint 6.4.1 (version in the upstream folder)?

With pleasure!

Cool. I have finally a way to generate the Deb file using debhelper. Though maybe that won't work for you because I am using lazbuild as well.

Hum, I have allowed myself to answer these false accusations: here

I see. Thaddy complaints much, even when there is nothing to complain about. Thanks for restoring some facts.

(And maybe, if you read all the posts, you will understand why I was not too hot to install Lazarus on Rpi and prefer to compile LazPaint via ideU).

So I presume that you cannot use lazbuild in the terminal?

[fredvs]

I see. Thaddy complaints much

Yes, I even give him his slogan few years ago:

For you Thaddy: "Read once, before to comment everywhere".

[fredvs]

So I presume that you cannot use lazbuild in the terminal?

If it calls Lazarus, sorry but for FreeBSD and Rpi I really fear that I will not find the time, the energy and the courage to try to install it.

[fredvs]

So I presume that you cannot use lazbuild in the terminal?

Compilation of LazPaint works with ideU, the only thing that is missing for a out-of-the-box command line is the macro LCL used by ideU.

If you can find a trick in lazbuild to assign the root directory of Lazarus source, it should work.

[fredvs]

So I presume that you cannot use lazbuild in the terminal?

Ooops, me too I have to read better, I did read "lazpaintbuild".

So, trust me, I did try (a lot) to install Lazarus with lazbuild in the terminal, I fail on Rpi and FreeBSD.

[circular17]

Could the solution be as simple as to copy'n'paste the FPC command line generated by ideU?

[fredvs]

Could the solution be as simple as to copy'n'paste the FPC command line generated by ideU?

Yes but the FPC command line generated by ideU transform the macro LCL into the root directory of Lazarus source.

By the way, did you ever try to isolate the LCL sources needed to compile LazPaint? Imho it should be interesting to have the list of all the units needed.

[circular17]

Could the solution be as simple as to copy'n'paste the FPC command line generated by ideU?

Yes but the FPC command line generated by ideU transform the macro LCL into the root directory of Lazarus source.

Ok. Another option would be make a script to generate the Debian package from compiled file, as I did for version 7.1.3. Can the ideU project output the compiled binary at the same location as Lazarus does?

By the way, did you ever try to isolate the LCL sources needed to compile LazPaint? Imho it should be interesting to have the list of all the units needed.

That would be a good chunk of it probably. I don't really have the motivation to make such list.

[fredvs]

Can the ideU project output the compiled binary at the same location as Lazarus does?

Of course but there is one thing that I dont like too much is to create the directories. With fpGUI, MSEide and many others the output directories are already created and part of the source.

And because github dont allow to commit empty directories, each sub-directory of units has a "dummy.txt" file of 0 byte.

For ideU, there is only /ideu/src/units/dummy.txt, no sub-directory.

But for fpGUI for example is created already all the sub-directories by cpu-os in units: /units/x86_64-linux/dummy.txt, /units/i386-linux/dummy.txt, /units/x86_64-freebsd/dummy.txt, /units/i386-linux-linux/dummy.txt, /units/x86_64-windows/dummy.txt, /units/i386-windows/dummy.txt, etc.

And at compilation, one of those directory will be used and no need to create any new directory.

[circular17]

There is a misunderstanding. I am just talking about lazpaint binary in the bin directory.

[fredvs]

There is a misunderstanding. I am just talking about lazpaint binary in the bin directory.

Ha , ok, of course yes, you need to change Target Pref in Project Option make and set it to -orelease/

[circular17]

Ok. Is it possible to compile and ideU project from command line?

[fredvs]

Ok. Is it possible to compile and ideU project from command line?

Huh, yes, for example in MSEgui readme.txt it is explained how to compile MSEide from command line.

So, imho, it should be possible for everything. But I never try it.

[fredvs]

I dont really understand what you want to do. Do you want to make a script that loads ideU?

Why not do a complete independent script? The only thing to find is a way to assign the root directory of Lazarus source. Or include in your source the Lazarus units needed for LazPaint.

[circular17]

Just thinking about different options. Either I need the path of ideU or I need the path of LCL. So in all cases, that requires to configure it.

[fredvs]

Yes, it is a good challenge.

I think I would vote for a kind of lazpaintbuild.cfg where people has only to write the root directory of Lazarus. But there are lot of other options, like using "locate lazarus.lpi" to automatic find the directory.

[circular17]

There can be a lot of lazarus.lpi so probably asking the user to define which one sound better to me as well.

[fredvs]

There can be a lot of lazarus.lpi so probably asking the user to define which one sound better to me as well.

Yes, imho too. But how will you ask this, via the terminal or via a config file?

This question is not evident to answer because if you ask it via terminal, the user has to enter the directory each time, with the config file he needs to do it only once.

But via the terminal it is more all-in-one.

So the choice will not be easy (terminal vs config file).

[circular17]

Well it is rare to compile software from source. Or if you are changing the files and testing what happens, you can keep the terminal open.

[circular17]

Now I am stumbling upon the lazpaint.res. As I don't have windres, I cannot generate it. So without Lazarus, I am a bit stuck.

[fredvs]

As I don't have windres

Hum, for this you may ask people to install it on Linux:

$ sudo apt-get install mingw-w64 $ sudo ln -s /usr/bin/x86_64-w64-mingw32-windres /usr/bin/windres

It should be installed in fpc Windows by default.

[circular17]

Hmm sure, but that's 744 MB to install, for a tiny little resource file.

[fredvs]

Now I am stumbling upon the lazpaint.res

Not understood, I was thinking that the goal of lazpaint-upstream was to give all needed to compile LazPaint.

[fredvs]

Hmm sure, but that's 744 MB to install, for a tiny little resource file.

Yes and only copying windres will not work because windres needs gcc. Sincerely, I dont understand why you dont want give the lazpaint.res in source. (Even if it is a crime)

[circular17]

Well, I might end up doing that even if it is a crime. I just not going straight for the easy solution.

For a Debian package to build, it must not replace an existing file. So I cannot provide it as lazpaint/lazpaint.res, though I can provide it in another folder.

[fredvs]

Maybe I did not catch something, there is /lazpaint-upstream-master/lazpaint/fpc-res.res, so why not lazpaint.res?

[circular17]

Oh, those are unused files and they are not generated at all anymore. But well there is not point having them, so let's remove them.

[circular17]

Ok I found a small package to install: binutils-mingw-w64-i686. It takes up only 20.8 MB. I am going to try that.

[fredvs]

binutils-mingw-w64-i686

Is it not 32 bit only ?

[fredvs]

Is it not 32 bit only ?

Stupid question, ignore it.

[circular17]

I am not sure but I suppose the RES file is the same anyway.

[fredvs]

I am not sure but I suppose the RES file is the same anyway.

Exactly and if your system is multi arch, no problem if it is 32 bit.

[fredvs]

Huh, are you doing all this on a Rpi?

[circular17]

Well I suppose the program itself is compiled for the current architecture.

But it complains about not finding i686-w64-mingw32-gcc. I am surprised apt did not say it needed more stuff.

[fredvs]

But it complains about not finding i686-w64-mingw32-gcc.

Yes I know, windres needs gcc.

[circular17]

That seems unnecessary

[fredvs]

That seems unnecessary

What, gcc ? Yes it is strange but it is the way that windres is constructed.

[fredvs]

If it is for you only, you may use wine + windres.exe, it works.

[circular17]

It is for the script.

I found a solution: using the option --preprocessor cat

Normally the preprocessor may change the code and outputs the result to the console. But there is nothing to change, so simply using cat will send the file as such to the console.

[fredvs]

If I may, usually {$R myicon.rc} is used only for Windows.

For example in MSEide code, Martin did use that:

{$ifdef mswindows}
 {$R mseide.rc}
{$endif}

Because on Linux there is no icon for the executable. Why dont you assign with Lazarus, a icon for the form, like for MSEgui or fpGUI? And the ressource of that icon stored into the lfm file?

[circular17]

That's a good point. Maybe we don't need that RES file at all.

[fredvs]

If you agree to have individual icon for each form and not use the one from {$R lazpaint.rc}, yes.

[circular17]

Oh I see. Hmm I don't know. Well anyway for now that works with the trick I mentioned.

Now I have another problem. If I get the FPC command line from ideU, it seems to contain something specific to the platform, it calls ppcx64. So if I write a script, it would have to guess which FPC to call? ppcx64 -orelease/lazpaint -Fu./buttons -Fi./buttons -Fl./buttons -Fo./buttons -Fu./image -Fi./image -Fl./image -Fo./image -Fu./cursors -Fi./cursors -Fl./cursors -Fo./cursors -Fu./buttons -Fi./buttons -Fl./buttons -Fo./buttons -Fu./* -Fi./* -Fl./* -Fo./* -Fu../bgracontrols -Fi../bgracontrols -Fl../bgracontrols -Fo../bgracontrols -Fu../bgrabitmap -Fi../bgrabitmap -Fl../bgrabitmap -Fo../bgrabitmap -Fu$lazdir/* -Fi$lazdir/* -Fl$lazdir/* -Fo$lazdir/* -Fu$lazdir/components/printers/unix -Fi$lazdir/components/printers/unix -Fl$lazdir/components/printers/unix -Fo$lazdir/components/printers/unix -Fu$lazdir/packager/registration -Fi$lazdir/packager/registration -Fl$lazdir/packager/registration -Fo$lazdir/packager/registration -Fu$lazdir/components/* -Fi$lazdir/components/* -Fl$lazdir/components/* -Fo$lazdir/components/* -Fu$lazdir/lcl/forms -Fi$lazdir/lcl/forms -Fl$lazdir/lcl/forms -Fo$lazdir/lcl/forms -Fu$lazdir/lcl/widgetset -Fi$lazdir/lcl/widgetset -Fl$lazdir/lcl/widgetset -Fo$lazdir/lcl/widgetset -Fu$lazdir/interfaces/* -Fi$lazdir/interfaces/* -Fl$lazdir/interfaces/* -Fo$lazdir/interfaces/* -Fu$lazdir/lcl/nonwin32 -Fi$lazdir/lcl/nonwin32 -Fl$lazdir/lcl/nonwin32 -Fo$lazdir/lcl/nonwin32 -Fu$lazdir/lcl/interfaces/gtk2 -Fi$lazdir/lcl/interfaces/gtk2 -Fl$lazdir/lcl/interfaces/gtk2 -Fo$lazdir/lcl/interfaces/gtk2 -Fu$lazdir/lcl/components/* -Fi$lazdir/lcl/components/* -Fl$lazdir/lcl/components/* -Fo$lazdir/lcl/components/* -Fu$lazdir/lcl/include -Fi$lazdir/lcl/include -Fl$lazdir/lcl/include -Fo$lazdir/lcl/include -Fu$lazdir/lcl -Fi$lazdir/lcl -Fl$lazdir/lcl -Fo$lazdir/lcl -MObjFPC -Scgi -Cg -OoREGVAR -Xs -XX -l -vewnhibq -VD -O3 -XX -CX -Xs -vi -FUunits/ -dLCL -dLCLgtk2 lazpaint.lpr

[fredvs]

would have to guess which FPC to call?

Yes, using fpc vs ppcx64 should work. Is it not working for you?

[circular17]

Hmmm, I just tried, and it wrote this: Failed to execute "ppcx64-D", error code: 127

[fredvs]

Hmmm, I just tried, and it wrote this: Failed to execute "ppcx64-D", error code: 127

Please, explain better, do you try with a command line in console or from ideU?