Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Freepascal has been working on a package system of its own in a cross between apt-get and freebsd ports style. (download source/build/install automatically), called fppkg. However work has stalled. People investing time are the bottleneck, not people wanting to choose tools.</p> <p>As far as Maven goes, I don't like auxilary tools that need installation of huge external runtimes. It might be fine for a big major app (like Open Office), but not for an util.</p> <p>I also prefer a tool that is designed to the FPC reality and workflow. Documentation tools, build tools, download systems, testsuite systems are already all there, it just need a person that dedicates a lot of time into it to make it happen.</p> <p>Some typical problems when introducing a new technology in a project as FPC, and why it has a tendency to make its own tools:</p> <ul> <li>need to train 20+ committers in parttime.</li> <li>The only COMMON programming language you can assume is Free Pascal. Even Delphi inner workings can't be taken for granted to be known (many committers came directly to FPC or even still via TP or a Mac Pascal) <ul> <li>Obviously that makes something with plugins in a different language annoying.</li> </ul></li> <li>Bash script is a close second. (g)make third, but already a magnitude less.</li> <li>All servers are *nix-like (FreeBSD, OS X, Linux), but not all run Apache. (e.g. my FreeBSD mirror runs XSHTTPD)</li> <li>somebody most knowledgable must be dedicated maintainer for a long time. Fix problems, update/ do migrations etc. Perferably more than one for obvious reasons.</li> <li>a major pain are Linux distributions (and FreeBSD to a lesser degree), most maintainers of *nix packages are not capable of more than "./configure;make;make install", and must be spoonfed with a near buildable repository and auxilary files. <ul> <li>In-distribution packaging of FPC/Lazarus has always been important, and is still increasing</li> <li>All distributions have their own special rules about metadata, depedancies, and how sources must be published. Particularly Debian/Ubuntu is very bureaucratic and slow.</li> <li>Most don't like third party auto-installers on top of their systems (since that bypasses their dependancy control)</li> </ul></li> </ul> <p>This all leads to the effective practice that own tools in Pascal with minimal scripting work best. Some tools used:</p> <ul> <li>Gmake is mainly used to parameterise the build process on a per directory level, a successor, fpcmake (not really a make derivative despite the name) has begun, but the migration hasn't completed.</li> <li>Latex and a latex to html conversion (tex4ht, but debian uses hevea) are used in the documentation building (the non library documentation)</li> <li>The community site (netscape community server which uses TCL scripting, a heavy complex application server) has been a trouble ever since it started, but specially lately since the maintainer became less active.</li> <li>Mantis has been a problem (specially the email module would crash or lame the server due to the volume), but it has been whipped into shape during successive updates and hard work of several lazarus devels. Currently it is a decent workhorse.</li> <li>lazarus.freepascal.org PHPBB forum OTOH is relatively painless since a lot of younger people know how to deal with it. </li> <li>The same goes for subversions (though the more advanced scale needs some adjusting, not everybody is deep into the ins and outs of mergetracking)</li> </ul> <p>If somebody was really serious about Maven, I usually would ask him:</p> <ul> <li>to <em>CRITICIALLY</em> investigate the use for the project. In a very concrete way, with schedule and time estimates. Birds-eye level "everything's possible" overviews are essentialy worthless.</li> <li>Give some thought on future change of used technologies. Every technology is eventually replaced, even the in-house ones, in 18 year+ projects. A new technology must not make migrations of other infrastructural components hard or involved. The new technology to end all new technologies doesn't exist.</li> <li>Make a migration plan. Migration is often underrated and underestimated.</li> <li>And in the end, there is always the 1000000 Euro question, who will do the daily maintenance?</li> </ul> <p>Keep in mind that in a company you just kick the person responsible for the application server. But in an informal environment this is way harder, specially long term, since people's lives, occupations and time spent on the project vary.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload