Hi, What do I need for crosscompilation on Linux for Win32

Did you try docs/CrossCompile.txt?

Mattias

Eh... ofcoarse not :)

Hey, we have a docs section :)

OK, nothing asked.

Hi,

What do I need for crosscompilation on Linux for Win32

Marc

Check out SQLite. It is text based and a simple
interface for Delphi has been written (I think you can find it on the torry site ( http://www.torry.net ) and do a search for sqlite. Its not graphical so it
should be easy to get to work.

_________________________________________________________________

To unsubscribe: mail with "unsubscribe" as the Subject archives at

http://www.lazarus.freepascal.org/mailarchives

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

The whole dbctrls.pas does not exists. The FCL part (db.pas and a database) is there. So, I think, this is the main missing thing.

Even with the problems on the backend with data connectivity, it would put us a step closer and certainly someone could develop a simple text file based database component to hook the TDatasource into.

Who is someone? ;)

Just as I mentioned that adding custom components to the palette would really jumpstart Lazarus usage

Eh. Did it?

.. not counting the questions, where to find docs and how to install under win32 ..

I recall for D4 there were a few freeware text file based TTable components... or perhaps something like MyLittleBase could be used with data aware components with a little work.

Maybe.

Some notes about dbctrls.pas:
- Long time ago, someone came up with the idea, to add some datalink ability to TControl, so that implementing data aware controls would be easier. I don't know, what exactly he had in mind. Maybe someone with more experience about db controls knows.
- The controls in dbctrls.pas use a lot of messages. This should be avoided, because the LCL interfaces will implement those special messages at last, if at all.

Mattias

AHA! someone else thinking like me. I have already begun looking at making a basic TDataset front end for the MyLittleBase code, which looks like it should work fine in FreePascal. Supports its own custom format, csv and isam. Tests under Delphi work well, if incomplete not having ever done this before. I will see how far I can take it and how much if anything needs to be done to make it work in lazarus/fpc. I figure if I can get it going ok it would mean lazarus could ship with very basic db support compiled in since text tables don't require servers or external libs etc. Obviously it will be limited, no lock handling, nor multithreading capable either.

Also dependent on how it goes I will be seeing how hard it will be to make a more advanced(and TQuery/TTable like version) of interbase components. For the moment I am looking at those IB components posted on the list awhile back since I am not familiar with direct ib/fb api, I can make the dataset simply a wrapper around the real components etc.

This has been one thing which I feel has prevented easy extension of DB aware controls, lack of good simple dataset components available to all.

I will put online an initial version as soon as I can get it compiling under Lazarus/fpc1.0.10(or if need be 1.1 though preferably not yet).

Andrew

Realize I'm not really a power programmer when it comes to internal workings of the LCL / VCL... Looking at the source code on this doesn't really help me much, I've tried.

So my question is, how close is Lazarus to having data aware components such as TDBEdit?

Even with the problems on the backend with data connectivity, it would put us a step closer and certainly someone could develop a simple text file based database component to hook the TDatasource into.

Just as I mentioned that adding custom components to the palette would really jumpstart Lazarus usage (and it wasn't too long before that happened) I think it's time we started working on an interim database component for simple projects. Something palette based drag-n-drop.

If you remember, for a while the most common question of new folks (yes, I live in the "South") was how to add components to the IDE. Now the most common question appears to be "how do I use a database?"

I recall for D4 there were a few freeware text file based TTable components... or perhaps something like MyLittleBase could be used with data aware components with a little work.

-Tony

I have also a working TDataset descendent for sqlite, it's not yet committed, as I was waiting for feedback from someone. But if there is enough demand, I will commit it.

Michael.

Maybe we can make some busybox version in FPC to use on non *nix platforms?

Currently the Makefile doesn't support cygwin. Adding support to the Makefile is not easy because it needs more exceptions to look for install.exe instead of ginstall.exe etc.

And also because of this.

So detect ppc386 source, and if os_source=win32 or go32v2 (and maybe others), INSTALL=mybinary -i
PWD= mybinary -p

etc etc.
?

The sqlite interface is in fpc CVS already btw.

/fpc/packages/base/sqlite

Reading this, I would suggest having a look at
http://www.suigeneris.org/want/ as a build tool.

Want is XML based, written in Delphi and does its job quite well. One major advantage of
Want is, that is does not depend on shell commands.

On the downside its written using Interfaces here and there, which makes porting to FPC a little
more work than usual. Maybe we could use a Kylix/Delphi version until FPCs Interfaces
implementation is stable (its in 1.1, isn't it?)

What do you think?

-Stefan

Sounds the same to me ? One is graphical, the other not :-)

A Makefile is file based, supports a lot of macros and uses the environment vars. Lazarus otoh is package based, supports inheritance and no variable depends on external programs.

I think that it should be possible to create a makefile based on a lazarus package file, the makefile can then be used to do command-line building.

So, when combining both systems, we will loose some of the Makefile abilities.

In general, we don't use most of the abilities anyway, so this is OK.

fpcmake is not a must for me, but we need something to steer compilation, independent of the IDE.

Michael.

Package based is better for pascal units. Pascal units don't need the Makefile file dependency support. A program that has ppu file knowledge can give that information much better.

Having the posibility to run pre- and post-build commands that can do some preprocessing/checking will make a package based tool already very powerfull to do some more complex tasks

I don't know. Here's the original package (154k)... the readme.txt contains the license:

http://delphi.icm.edu.pl/ftp/d20free/sgraph24.zip

I used sgraph quite a bit with D5 and it's great for multi-axis plotting. It was easy to convert except for the series unit (sgr_data) that uses variants. Hopefully the 1.1 release will compile it.

-Tom

Keep using make, but replace all other utils on non unix systems.

If we really would replace make, it would become a huge effort, with a hard transition time.

I think we should regard FPC and Lazarus as stuff that only developpers/maintainers build (using make),
while lazarus packages are typically made by users.

It is natural to keep that apart.

I agree that XML is not very human-readable and should be edited using a GUI editor which is yet to be created...
On the other hand it is not that hard to write once you've spent a little time with it, i've tried it qith a number of projects, most of them could be setup using cut'n'paste.

The advantage of XML is that it maps directly to the internal object structure used in Want.

Also the system requirements must be really low (preferably depend on RTL only, and _maybe_ on classes)

The Idea of Want is to include all necessary funtionality for the build process and releated tasks. Therefore it uses a lot of library stuff, namely the JCL and JAL (a library written by the author of Want and included with the source).
We need not port all of the Want-Tasks to start with. Some of them are responsible for quite a number of Uses,
e.g. FTP upload.

You can have a look at the docs for ANT (the Java build tool which inspired WANT) which follows
the same structure.

I see a lot of units that import windows or VCL/CLX classes though.

Which? I've just checked the source and found no VCL/CLX stuff except for IniFiles.pas
and the Win32 stuff is just for the console window.

-Stefan

CVS has means for this, this is no problem.

Yes, and very win32... But powerful.

Michael.

I totally agree and I would like to help.

Mattias

I forgot one of the most complex things of the Makefile's: the unix-tools you need like install/date/echo/pwd. For every platform we have to collect these tools. The most difficult platform sofar was Windows where we needed native win32 apps.

Currently the Makefile doesn't support cygwin. Adding support to the Makefile is not easy because it needs more exceptions to look for install.exe instead of ginstall.exe etc.

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

I have recently set up a CVS repository for such things on the FPC server

cvs co contrib

will check it out for you. Currently it contains TurboPowers Abbrevia (handles zip, tar .gz and the like) and also systools (system routines) both compile and work with FPC. There is also a package for symbolic math from Marco Van De Voort Soon we'll add a version of Francois Piette's ICS (Internet Component Suite) too, as well as some other Turbopower sources. (Onguard and Lockbox, both encrypting tools)

A dream of me personally would be Turbopower's Orpheus. (a huge set of visual classes).

I plan on making daily zips/builds for these things as well. But we're still thinking about a good package format. Maybe a mix between fpcmake and lazarus package manager would be good, if we can make the package manager in a command-line version.

Michael.

I'm all for it. Like I said, fpcmake is not a must, but a command-line tool is.

Michael.

... But we're still thinking about a good package format. Maybe a mix between fpcmake and lazarus package manager would be good, if we can make the package manager in a command-line version.

Regarding package design, I'll toss in something that I've come across a few times when converting existing code.

The release docs for the SGraph package state that the sources can only be redistributed in an unmodified form. I've tried to contact the author about waiving this requirement but haven't been successful... so for the moment, we're stuck with applying diffs before the compile/install.

I'm not sure how often this will come up, but it would be easier to deal with if the packager could run a pre-install script (like rpm and deb) that would automatically apply the patches.

-Tom

I doubt that you can create a standalone Makefile, because it must be able to parse xml files and check topological. Of course you can parse the xml files and then create a Makefile, but this will only work on your computer, unless you make sure, that all packages are in fixed locations.

Such a tool is one of my top todos.
We need also a tool to edit the packagelinks.xml file at command line.

Mattias

> ... But we're still > thinking about a good package format. Maybe a mix between fpcmake and > lazarus package manager would be good, if we can make the package > manager in a command-line version.

Peter Vreman had the same idea and I like the idea too. But in general, fpcmake and the lazarus package system are quite different. fpcmake is a Makefile generator and the other is a graphical dependency manager for fpc commands. A Makefile is file based, supports a lot of macros and uses the environment vars. Lazarus otoh is package based, supports inheritance and no variable depends on external programs.
So, when combining both systems, we will loose some of the Makefile abilities.
The first step is to reorder some of the package system code ...

Is it possible to distribute a modified version plus the original sources?

Hmm. Sounds like distributing a modified version plus the original sources. But I'm not a lawyer.

Mattias

Count me in :-)

"Someone" could be a person who likes this idea a lot, has the time and ability and decides to make it happen. I like the idea a lot... wish I had the time and ability! :)

> Just as I mentioned that adding custom components to the palette would > really jumpstart Lazarus usage Eh. Did it?

It did for me.

Tony's component pack announcement is why I gave Lazarus another try last Spring. The stability of the IDE got me hooked... but a loaded component palette looks mighty attractive to a migrating developer!

There are a *lot* of existing components for Delphi that could be converted with minimal effort. I've been hoping to see some requests for components and libraries that the folks on the list are looking for. Michael's component repository idea seems like an ideal approach... is anyone else interested? If so, registering a Sourceforge project for it might be a quick and easy way to get it started.

-Tom

Agreed with all these difficulties. But what is the conclusion ? Make a complete new tool which does everthing itself, based on/compatible to the lazarus package tool ?

Michael.

I think also that it is better to keep it in an CVS under our control instead of SF. Writing some scripts to generate CVS write accounts (without shell access) shouldn't be that hard :)

A dream of me personally would be Turbopower's Orpheus. (a huge set of visual classes).

What's the problem with compiling it? VCL-based?

I don't like XML for manual editing. I prefer .ini files, or keyword based config files over them.

Also the system requirements must be really low (preferably depend on RTL only, and _maybe_ on classes)

Needing 1.1 to compile isn't that bad I think, but transfering without having it run under FPC native is absolutely out of the question.

Licensing and the fact that FPC is more than just Delphi/linux-i386 (and a few major linuxes only even).

What do you think?

There don't seem to be much docs, so it is hard to say.

I see a lot of units that import windows or VCL/CLX classes though.

Tom Lisjac wrote

Just to clarify, the idea of creating a Sourceforge component repository wasn't intended to compete with the existing sites.

Understood that.

Very true. In most cases a component conversion can start and be done in a matter of weeks if all of the tools are available in Lazarus and the FPC. It would add extra effort to the current web site.

As was indicated this allows for bug tracking and CVS etc for each individual little project just for the time period that it is alive.

However what we can do is link all of the projects "Home Pages" to the main web site. I can create a projects database that will list all of the ongoing projects available with discription, yadda, yadda. That way they can all be easily found from one location. It also means that when the component is complete the sourceforge site can be taken down but the "Home Page" location for the component can still exist.

I can also add some forum categories for projects so they can be discussed there.

Sourceforge and Freshmeat also provide a press release system that could help to attract new users and developers. Thousands of techies drink their morning coffee while browsing these sites. Each new component release would be an opportunity to introduce them to Lazarus and FPC.

Even though I can also provide the CVS for the projects the above alone would make it worth while to do this on sourceforge. Anything to help get the word our and bring in more support.

Comments, suggestions and participants are welcome.

If you want to do the "Home Page" thing as I have outlined I can setup the database and pages so that it is ready to link to projects as they develop.

Talk at you later,

Just to clarify, the idea of creating a Sourceforge component repository wasn't intended to compete with the existing sites. The IDE and compiler projects are long term efforts with a small, dedicated and highly competent core group. The existing sites support this model perfectly.

The development model for converting components is quite different. It would work well with short commitments for small projects from a large developer pool of varying skills... the more the better! Sourceforge has an advantage here because it provides a lot of automation that supports the management of multiple developers and tasks. The less time the core team spends managing, the more code they'll be able to write.

Converting components is an ideal place for a new user to start. The SF site would provide a point of entry where they could get familiar with Lazarus while also helping to fill up the component palette. Separate bug tracking and mail lists for this project would also help keep the noise level down on the IDE and compiler development lists.

Sourceforge and Freshmeat also provide a press release system that could help to attract new users and developers. Thousands of techies drink their morning coffee while browsing these sites. Each new component release would be an opportunity to introduce them to Lazarus and FPC.

These are the basic reasons for considering Sourceforge to host this type of project. Comments, suggestions and participants are welcome.

-Tom

Vincent Snijders wrote

Michael, why don't you put an update on lazarus on freshmeat. They still think we lot has changed since then.

That is on my todo list. I was waiting until I got this upgrade done so just in case it got a heavy load (slash dotted, yeah right) it could handle it better. :-)

Michael, why don't you put an update on lazarus on freshmeat. They still think we lot has changed since then.

Regards,
Vincent.

When 'make' lazarus, it stop with this:

When you update, always use something like this

cvs -z3 update -dP && make clean all

Mattias

When 'make' lazarus, it stop with this:

Compiling encloseselectiondlg.pas
encloseselectiondlg.pas(197,18) Error: Identifier not found BCFINDENTEXISTINGLINEBREAKS
encloseselectiondlg.pas(197,46) Error: Identifier not found BCFDONOTINDENTFIRSTLINE
encloseselectiondlg.pas(425) Fatal: There were 2 errors compiling module, stopping
make[1]: *** [lazarus] Error 1
make[1]: Leaving directory `/root/Desktop/lazarus/lazarus' make: *** [ide] Error 2
lazarus]#

OS: Linux
Lazarus: 20030831CVS
FPC: fpc-1.0.10-0.i386.rpm

--------------------------------
Cordiales saludos
Manuel P�rez L�pez

http://www.ieduca.net/