Recent

Author Topic: Forking/Flavouring Free Pascal and Lazarus  (Read 12963 times)

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Forking/Flavouring Free Pascal and Lazarus
« on: April 06, 2015, 10:30:56 am »
   The following post contains: foreword, flavouring example, flavouring and forking

   Foreword
   Because the community is small, developers that don't agree with core ones have two choices: fight them over svn trunk or fork the project. We've all seen that once or twice a year an argue starts between some core developers and other developers. Some of the poorly satisfied developers started building their own forks. This lead to an increased fragmentation of the community. I think the forking policy didn't helped much most of those developers either. I know that there are forks under development and I think that people who consider starting new ones might be interested in the following text.


   Flavouring example
   Flavouring is a code modification process done against "vanilla"(original) code. In this example, it can be done over latest stable or unstable(svn) Lazarus code. To be frank, it can be done against forks(like CodeTyphoon) too. If I explain right and you have imagination then there's no need for you to download any of the following files. The forum topic has a number of files attached as archives(just for presentation purpose):
   fce.fcs - is a file that contains data about flavour changes. It's something like a binary "patch" or "diff" file.
   fcsconsole - is a binary console client that patches the *.fcs files. It's something like the free pascal included "patch" binary.
   externaltools.xml - is an xml file used at LazarusMenu/Tools/Configure External Tools ... . It's purpose is to have graphical menu entries instead of manually typing in a terminal.

   In order to apply the flavour(from scratch) a developer has to:
   WARNING! BACK-UP THE LAZARUS DIRECTORY! JUST IN CASE! MAKE SURE YOU HAVE THE RIGHTS TO MODIFY THE LAZARUS DIRECTORY!
   1/4 Copy in your home folder the "fce.fcs", "externaltools.xml" and the "fcsconsole" binary for your platform.
   2/4 In Lazarus, goto LazarusMenu/Tools/Configure External Tools ... and click on More >> Import .. . Select the "externaltools.xml" file. Click ok, you'll notice two entries under LazarusMenu/Tools/Configure External Tools ...
   3/4 Apply the flavour by clicking on LazarusMenu/Tools/FAST CODE EXECUTION FLAVOUR INSTALL or uninstall the flavour by clicking on LazarusMenu/Tools/FAST CODE EXECUTION FLAVOUR UNINSTALL. The process takes about 10 seconds.
   4/4 It's not mandatory but it's highly recommended to Rebuild the IDE.
   That's it! You have added a flavour to vanilla Lazarus.
   
   
   Flavouring and forking
   I think the steps presented above are easy enough for many users to be able to install a flavour. Instead of arguing with some core developers, a flavour can reach the community much faster than forks or svn branches, independently of core developers will. This means that the argues over development direction or priorities might decrease in number and "negative" energy, within the community.
   Look at abandoned fork projects. Even if most of the code gets into trunk and stable releases, it won't get 100%. Remember the debate on the message window colours. One wants a colour, another one wants a different font, one is interested in less bugs, one is interested in code readability, another one in code execution speed, one in weird experimental changes and so on.
   Multiple flavours may be applied at the same time. For example, "fast code execution" flavour may be applied after a "free sparta" flavour that has been applied  after a "nightly build" flavour that is applied on latest stable "vanilla" release. You should be able to add a new flavour, "CosmosIDE"(that adds tons of new packages for example) on top of the previous ones. Indeed, during this process some functionality may be lost due to code conflicts, but I think it's far from being a dramatic situation. This "diversity" management is something that I'm not sure you can easily maintain using branches or forks.

   I might be wrong, but maybe you should consider creating a new flavour instead of a new fork. I would appreciate if the attached files would be used only for the purpose of the topic.

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #1 on: April 06, 2015, 10:31:43 am »
Windows 32bit attachement

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #2 on: April 06, 2015, 10:32:19 am »
Linux 64bit attachement

lainz

  • Hero Member
  • *****
  • Posts: 3809
  • Leandro Diaz
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #3 on: May 03, 2015, 10:53:29 pm »
this is interesting i see the point of this. is like an advanced patch.
https://lainz.github.io/
Download LazPaint https://lazpaint.github.io/
Download BGRABitmap and BGRAControls https://github.com/bgrabitmap

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #4 on: May 30, 2015, 02:31:03 pm »
this is interesting i see the point of this. is like an advanced patch.

   Yep, kind of. Depending on how the code changes are internally written(and saved to ".fcs" files), the possibility to "patch" code on demand increases. This is just one step closer to have a fully automated delta server. For those that don't know what a delta server is, it's a server that automatically builds patch files upon request(usually text files). For example, if you have version 1.0 installed, instead of downloading the entire new version(2.0) of LibreOffice you try to download a file from http://deltaserver.com/openoffice_1.0_2.0.tar.gz. The server creates the patch file on demand(automatically), reducing download sizes. Also, you would be able to modify your own development instance(like your private modified version).
   The fcsconsole client is able to run external applications, many of them shipped within(inside) the ".fcs" file. This has the potential to "flavour" empty directories, which may be translated to "installation from scratch". Maybe projects like mseide would benefit from that, but I don't even know how to set-up fpc to cross compile at the moment(I never needed that).
   I've considered doing some tests with FreeSparta, but hnb followed a different approach. FreeSparta had the potential to become challenging because it needed both Fpc and Lazarus to be modified. Also, hnb worked on implementing it with CodeTyphoon too, meaning that being able to flavour both Lazarus and CT would have been additionally challenging.

Thaddy

  • Hero Member
  • *****
  • Posts: 10602
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #5 on: June 19, 2015, 10:43:54 am »
I don't see  any difference from branching/syncing.
BTW I hate kaleidoscopes and fragmentation in general.
Better discuss and get out of the eurozone ;)

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #6 on: August 14, 2015, 03:16:15 pm »
   I'd like to do an experiment with fpc and fpc based apps(mostly fpgui, mse*, Lazarus...). The experiment involves using a closed source software called Flavouring Control System(FCS). FCS is something like an advanced patching system. It can modify files not only depending on the available HDD content, but also on data gathered using external applications. For example, modifying source files depending on "fpc -iX" output. FCS uses symbols(defines), macros, possibility to run external programs, setting an order in the way files are being modified, storing/exporting data(text or binary) within/from flavour files, internal scripting and so on, everything done on the fly. I think it's a much more complicated application compared to a simple "patch" one, but this doesn't mean it's better suited for specific activities.
   Now, FCS is already advanced enough to start acting as an installer, too. Lazarus has it's own fpcup support, fpgui and mse* don't have something similar, CT is too advanced for this. Installation/configuration/updating can be a pain for new users. My proposal is:
- I try to develop two flavours, one that acts as an installer and one that acts as an updater.
- You agree to make the changes to your apps so that the apps won't conflict one with the other at the same level. Example: FCS installs fpc and fpgui trunk versions filling a default fpc.cfg file. After that, trying to install mse* will fail because it requires a stable fpc version and default fpc configuration file points to a development version. I don't think this is a good enough example as mse* can be built using fpc trunk too, but you get my point.

   If you would like to involve your application in this experiment, here is the first recommendation:
   After installation, some default settings should be inserted automatically by FCS into default configuration files. The problem is that after installation, these configuration files might not exist. Also, even if they exist, their possible location might be unknown or obsolete in terms of content and path. The same application can change the location of the configuration file depending on its version or whatever other reasons. This situation has to be managed somehow. My idea is to add a parameter to an application(I think the IDE is most appropriate). Passing this parameter(something like "--assureconfigurationfile"), will make sure a valid configuration file exists, file that contains all possible macro values. The application will return the full path of the valid configuration file and will exit immediately, like "fpc -iX" commands. FCS will use this file path to update the involved values. Storing settings by executing an external app with settings as parameters is ok, too. Failure to fulfill this recommendation might lead to totally useless installations as FCS might build your app with a fpc and its default configuration file that are not in PATH environment or within default values. That's not good for an IDE, is it!?
   If you would like to involve your app(IDEs are mostly targeted) in this experiment, you're welcome to reply to this forum subject.

mse

  • Sr. Member
  • ****
  • Posts: 286
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #7 on: August 14, 2015, 04:08:39 pm »
For MSEide macros can be set by
Code: [Select]
--macrodef=<name>,<value>{,<name>,<value>}
commandline parameter, please see README.TXT. The only macro which need to be set is "MSEDIR" for the root directory of the MSEide+MSEgui source tree and maybe "COMPILER" if the default setting is incorrect. Additionally used macros are "DEBUGGER" and "TARGETOSDIR" but there the automatically created values should suffice.

Graeme

  • Hero Member
  • *****
  • Posts: 1430
    • Graeme on the web
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #8 on: August 14, 2015, 04:34:26 pm »
I don't see  any difference from branching/syncing.
Yeah, I don't fully see the need for this "advanced patches type app" - Git already does exactly that for me. I use many open source projects. I always checkout there code with Git, and 99.99% of the time I have my own "custom-mods" branch where I maintain my own customisations which will only benefit me (thus no point in trying to contribute them back). Obviously things I feel could be useful to others I do contribute back, but there is no guarantee they will make it in. That doesn't bother me at all, because I can happily use those changes locally.

Git makes this process simple and painless. So I have best of both worlds. ;-)

Code: [Select]
  git checkout master     // switch to master and get read to fetch latest changes
  git branch -D graemeg       // throw-away branch where I do merging
  git pull
  git checkout -b graemeg   // create and checkout a new throw-away branch
  git merge custom-mods
  (build the project here)

Weeks or months later, repeat the above process.

As for the suggestion of adding a parameter to applications to generate a config file. I don't see the harm in that, but not everybody will feel the same way, so the FCS tool is going to have limited usage in the software out there.

My suggestion... learn to use git from the command line - thus no learning curve when switching platforms (Windows, OSX, Linux etc), plus you get ALL the functionality of Git. GUI front-ends always lag behind. Git is NOT hard to learn (don't be fooled by old reviews on the internet dating back several years). Git will change your world and very flexible, so you can apply the work-flow that fits your needs. No need for extra tools like fpcup.

Pro Git 2nd Edition - a free and open source book to learn Git. http://git-scm.com/book
Chapters are small and quick to read, with plenty of examples and pictures to help explain things.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

Paul Breneman

  • Sr. Member
  • ****
  • Posts: 290
    • Control Pascal
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #9 on: August 14, 2015, 05:30:56 pm »
No need for extra tools like fpcup.

Now you have my attention!  Both my Windows (ReactOS) and Linux (Debian) small virtual machine examples (http://wiki.freepascal.org/Small_Virtual_Machines) are stuck at getting fpcup (or requirements) to work.

Could Git be used (by a beginner) to help compile an ARM Embedded compiler for Teensy?  I'd like to see how simple it could be done!
Regards,
Paul Breneman
www.ControlPascal.com

lagprogramming

  • Full Member
  • ***
  • Posts: 159
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #10 on: August 14, 2015, 07:36:11 pm »
   I'm still looking forward for an answer from FPC, Lazarus and FreeSparta. CT is ignored from enumeration because it has it's own both installation&update system. To be crystal clear, lack of answer means no to me. I appreciate people that stand for their beliefs, Graeme is clearly one of them, even though I disagree with him.

   @mse
   I understand fpgui's decision expressed by Graeme, be kind and write mse*'s one. Your technical support may be useful, but I don't understand if you agree to be involved in this experiment or not. I would like a clear yes/no answer, reason why if you don't understand something just ask.

mse

  • Sr. Member
  • ****
  • Posts: 286
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #11 on: August 14, 2015, 07:57:40 pm »
I am glad to help by the experiment.
If I understand correctly you like to patch MSEide+MSEgui by means of a commercial patch tool and you need to setup the MSEide environment according your needs and propose to add a "--assureconfigurationfile" option to MSEide which creates a default MSEide global configuration file (~/.mseide/mseideli.sta on Linux) which can be patched.
Instead to patch the configuration file I suggest to run MSEide by a script and setup the environment macros by --macrodef parameter.
MSEide+MSEgui is hosted in a git repository
https://gitlab.com/mseide-msegui/mseide-msegui
so using git in order to patch it probably is more appropriate than a commercial patch tool.


Graeme

  • Hero Member
  • *****
  • Posts: 1430
    • Graeme on the web
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #12 on: August 14, 2015, 08:12:31 pm »
I understand fpgui's decision expressed by Graeme,
Just to be clear, I don't mind adding a parameter to Maximus IDE for you to experiment with. It is not too much effort for me, and you can continue playing with your experiment. ;)
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

Graeme

  • Hero Member
  • *****
  • Posts: 1430
    • Graeme on the web
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #13 on: August 14, 2015, 08:17:57 pm »
so using git in order to patch it probably is more appropriate than a commercial patch tool.
Exactly, and the last thing I want is to be dependent on commercial software so I can update open source software - it makes no sense to me. But I'll humour the guy and add the command line parameter to fpGUI's experimental IDE.

ps @lagprogramming:
Now if you used Git, you could have cloned fpGUI, created a branch with the new functionality (a new command line parameter), pushed it to some public server (Github, SF.net etc) and emailed me a pull request. That way I could review the change and update the official repository if the change was good. Just the way open source software collaboration should work. ;-)
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

Graeme

  • Hero Member
  • *****
  • Posts: 1430
    • Graeme on the web
Re: Forking/Flavouring Free Pascal and Lazarus
« Reply #14 on: August 14, 2015, 08:24:38 pm »
Could Git be used (by a beginner) to help compile an ARM Embedded compiler for Teensy?  I'd like to see how simple it could be done!
Well Paul, Git is available for pretty much any platform these days, so should run fine on ReactOS (like Windows if I remember correctly). Maintaining a public branch with build scripts, or pre-compiled build tools (though I don't recommend binaries in any code repository) is pretty easy. I didn't follow your "small virtual machine" discussions, so I don't really know what problem you are experiencing.

If you are not familiar with Git, please take a look at the Pro Git book - available online, offline HTML, MOBI, ePUB, PDF etc. Like I said, with such good documentation, anybody can learn the basics of git in a few minutes.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

 

TinyPortal © 2005-2018