From: "Mattias Gaertner"

The Makefiles were buggy. Some paths were wrong, no interface was compiled, cleaning was not clean,

some 'make all' did only compile the top file and a 'make' compiled the lcl three times. I fixed that.

And I've fixed the remaining problems on Win32.

Keith

The reason is that you use a go32v2 make.exe and a win32 ppc386.exe or a win32 make.exe and a go32v2 ppc386.exe. Both situations will not work as win32 has a 128 char commandline limitation between dos and win32 apps

Maybe you can add a simple writeln() and halt() to the abstract interface so it terminates nicely

unit to compile synedit in one step.

OK, this can be added there is special support for using such build allunits.pp

I've updated fpcmake and the Makefiles. The win32 build is now working, but the created executable just updated under linux, and guess what happended: It crashes here as well.

The reason is simple: No widget interface has been compiled.

The LCL needs a small trick to compile:

1. compile the lcl
2. remove lcl/units/interfaces.ppu
3. compile one widget interface (gtk or win32)

If you want to compile an additional widget interface, you must repeat step 2.+3.

In the current Makefile, this remove statement is missing, and so the LCL is abstract. Plz add such a remove to the Makefile.

Also the synedit is now build in 9 compile steps. There is a allunits.pp. Compile this unit to compile synedit in one step.

Mattias

No, sorry, had an exceptional heavy day on the job monday, and was at my parents today. Will do tomorrow morning first thing 8:30 CET.

Keith Bowes wrote

And I've fixed the remaining problems on Win32.

I do not know that has to see to clean the variables of entorno, but the exit is different.

C:\PP\LAZARUS>set path=c:\pp\bin\win32

C:\PP\LAZARUS>make
Ambiguous output redirect.
c:/pp/bin/win32/make.exe -C lcl all
Ambiguous output redirect.
make.exe[1]: Entering directory `c:/pp/lazarus/lcl' /PP/BIN/WIN32/rm.exe -f units/allunits.ppw
C:/PP/BIN/WIN32/ppc386.exe -dSUPPORTS_RESOURCES -gl -Fulcl/units -Fulcl/units/wi
n32 -Fudesigner -Fudebugger -Fucomponents/units -Fu. -Fiinclude -Fiinclude/win32
-FE. -di386 -gl -Fuinterfaces/abstract -Fu. -Fiinclude -FUunits -di386 allunits
.pp
Free Pascal Compiler version 1.0.5 [2001/12/19] for i386 Copyright (c) 1993-2000 by Florian Klaempfl
Fatal: No source file name in command line
make.exe[1]: *** [allunits.ppw] Error 1
make.exe[1]: Leaving directory `c:/pp/lazarus/lcl' make.exe: *** [lcl] Error 2

* CreatePixmapIndirect isn't completed; currently all bitmaps are 1x1-pixel black images.

BTW.
TBitmap, TPixmap and TIcon are not completed in the LCL. We need some conversion functions and resource managers. The idea is that the LCL is widget independent and has no knowledge about the handles. An image handle will be always the fastest type. That means, that a TBitmap.Handle will be a gtkpixmap under gtk and a win32 bitmap under win32. This is also true for TPixmap. The current LCL code is gtk specific.

Mattias

If you means Lazarus.

Under Linux. It compiles and runs well (but with the problem of the "Hints").

Under Windows. Not it compiles.

c:/pp/bin/win32/make.exe -C lcl all
make.exe[1]: Entering directory `c:/pp/lazarus/lcl' C:/PP/BIN/WIN32/rm.exe -f units/allunits.ppw
C:/PP/BIN/WIN32/ppc386.exe -dSUPPORTS_RESOURCES -gl -Fulcl/units -Fulcl/units/wi
n32 -Fudesigner -Fudebugger -Fucomponents/units -Fu. -Fuc:/pp/units/win32/rtl -F
uc:/pp/units/win32/paszlib -Fuc:/pp/units/win32/fcl -Fuc:/pp/units/win32/mysql -
Fiinclude -Fiinclude/win32 -FE. -di386 -gl -Fuinterfaces/abstract -Fu. -Fuc:/pp/
units/win32/rtl -Fuc:/pp/units/win32/paszlib -Fuc:/pp/units/win32/fcl -Fuc:/pp/u
nits/win32/mysql -Fuc:/pp/units/win32/opengl -Fuc:/pp/units/win32/gtk -Fiinclude
-FUunits -di386 allunits.pp
Free Pascal Compiler version 1.0.5 [2001/12/19] for i386 Copyright (c) 1993-2000 by Florian Klaempfl
Fatal: No source file name in command line
make.exe[1]: *** [allunits.ppw] Error 1
make.exe[1]: Leaving directory `c:/pp/lazarus/lcl' make.exe: *** [lcl] Error 2

You are in the correct thing, but the problem is in the distributions of FPC (make.exe of go32v2 in the packages of Win32).

I sought and I found a very good make.exe
(http://unxutils.sourceforge.net), but they follow the problems:

codetoolmanager.pas(1352,50) Hint: Parameter SENDER not used 26935 Lines compiled, 10.2 sec
MAKE.EXE[2]: Leaving directory `C:/PP/LAZARUS/components/codetools' MAKE.EXE[1]: Leaving directory `C:/PP/LAZARUS/components' C:/PP/BIN/WIN32/MAKE.EXE lazarus.res
MAKE.EXE[1]: Entering directory `C:/PP/LAZARUS'
windres -i lazarus.rc -o lazarus.res
GCC.EXE: installation problem, cannot exec `cpp': No such file or directory
windres: no resources
MAKE.EXE[1]: *** [lazarus.res] Error 1
MAKE.EXE[1]: Leaving directory `C:/PP/LAZARUS'
C:\PP\BIN\WIN32\MAKE.EXE: *** [ide] Error 2

The examples compile well, but not they function (to should function?)

I updated my fpc sources, but building fails with:

gtkglarea.pp(34,15) Fatal: Can't find unit GL

So, I took my old fpcmake and fixed the Makefiles. It compiles again under linux. Can someone check, if it compiles under win32 and bsd?

Mattias

From: "Luis R. Hilario" :

You are in the correct thing, but the problem is in the distributions of FPC (make.exe of go32v2 in the packages of Win32).

There is a makew32.zip file that contains Cygwin make and related utilities in a win32-1.0.6 directory on FTP, so I assume FPC 1.0.6 will come with the updated make.

This happened to me too, until I upgraded my make. I've also recently tried the new make_mingw32.exe version and that worked for me too. I don't know why you and Michael are having problems with this line.

The examples compile well, but not they function (to should function?)

The examples function for me. That is all but testall.exe and toolbar.exe. There are some things that are still be a bit buggy, but I don't claim that Lazarus for Win32 is bug free (it does compile, so it's a bit ahead of the GTK-Win32 version at this time):
* Because of how events are currently implemented, OnClick on menus don't work. I'll have to switch to a better events system later.
* CreatePixmapIndirect isn't completed; currently all bitmaps are 1x1-pixel black images.
* Adding a child to a TPage actually adds it to the page's parent TNotebook. I'll have to create a workaround later.
* Reacreating windows causes an exception.
* Closing the window opened in messagedialogs.exe crashes the app.
* In comdialogs.exe, the clicking Save button doesn't create a save dialog, though clicking Open does create an open dialog.

There may be a couple of other things that I missed. There has also been a recent regression of notebooktest.exe having pages added perpetually (until it stops responding), though notebk.exe still works.

Keith

That is correct. But since we are preparing a release the directory is 'closed' at the moment. It was mentioned that the make_mingw32.exe would be placed in the contrib/ dir, but i don't know if this is already done.

> I sought and I found a very good make.exe > (http://unxutils.sourceforge.net), but they follow the problems:

I know that make.exe. It also has problems. The only good version that works under win98 and win2000 is the mingw32 version.

Do you mean FPC or Lazarus?

I added an exception.

> Also the synedit is now build in 9 compile steps. There is a allunits.pp. Compile this unit to compile synedit in one step. OK, this can be added there is special support for using such build allunits.pp

The codetools needs also such a unit.
The source/target paths of the IDE, synedit and codetools are also wrong. I will update my fpc sources and try to get it working under linux again.

Mattias

I ment Lazarus.
The Makefiles were buggy.
Some paths were wrong, no interface was compiled, cleaning was not clean, some 'make all' did only compile the top file and a 'make' compiled the lcl three times. I fixed that.

Mattias

I've updated fpcmake and the Makefiles. The win32 build is now working, but the created executable fpcmake things:

The 'makefile' target is removed from all Makefiles. This is required because make has an internal rule to update the Makefile, this rule can't be disabled.

Running fpcmake without arguments will process the current Makefile.fpc and create a Makefile for the current target only. This can be overruled by the -T to specify the targets you want to build the Makefile for

New option -r to process directories in the [target] section recursively. This means running "fpcmake -r" in the top dir of lazarus will build all Makefiles

The default LCL platform for win32 is changed to win32

To build the generic Makefile that supports all platforms you need the FPC source tree and then run "fpcmake -r -Tall"

Peter

Yep. Will save time.
When you got to a point, where you really need it, just tell me. I'm currently improving find declaration til to the point that Object Inspector Events will work. But images are also important.

Mattias

From: "Mattias Gaertner" :

BTW. TBitmap, TPixmap and TIcon are not completed in the LCL. We need some

conversion functions and resource managers. The idea is that the LCL is widget independent and has no knowledge about the handles. An image handle will be always the fastest type. That means, that a TBitmap.Handle will be a gtkpixmap under gtk and a win32 bitmap under win32. This is also true for TPixmap.

The current LCL code is gtk specific.

So, I should forget about these things until a widget-independent way of doing it is thought of?