But that is the point. I have gcc.exe and cpp.exe located in the \pp\bin\win32 directory. It should be able to find them.

This is a known issue that we already discussed with the fpc developpers. The final solution that we are going to implement is:

"fpcmake -w" builds only for the current target. There will be a check added to the generated Makefile that compares the current target with the targets that the Makefile supports, when this doesn't match an error will be returned

"fpcmake -w -Tall" builds a Makefile for all targets

The automatic rebuild of required packages that are not yet build will be removed from the generated Makefile

Typing "make makefiles" from the topdir will build all Makefiles automatically for the current target. To generate the top Makefile i'll look if we can supply a bootstrap makefile

This is a bug. If you know how i can reproduce this i can look at it.

I've a patch for the Makefile.fpc/Makefiles to add support for lazarus/lcl and that fixes the synedit problem (missing gtk dependency). Also the rebuilding of the Makefiles is easier and works better. The previous rebuild check was an addition in the Makefile.fpc files and not added by fpcmake.

I already submitted the changes to Marc. He replied that he would look at it when he was back from a ski-trip. But if you want i can commit these Makefile.fpc changes

Peter

Greetings,

I have been pulling my hair out trying to get a good setup of Win32 to build Lazarus. Still not sure it is possible.

I have run across several kinks with regards to the Makefile.

Currently we are running:

fpcmake -w

every time we run make in a directory.

The problem is that the simple command:

fpcmake -w

will not work UNLESS you have additional directories in your FPC installation which would correspond to the actual source location for the various packages. Since we are not doing that in our Linux RPM and Win32 installs it causes no end of problems.

The only way around it would be to have it do a

fpcmake -w -T$(OS_TARGET)

That would build the Makefile just fine BUT it would only build it with the package information for that platform. Then if that gets committed people on Linux could be checking out a Win32 Makefile, etc. etc. etc. yadda, yadda, yadda. It gets to be a mess.

My question is,

Why are we forcing it to build a new Makefile every time we run make?

Doesn't make much sense since that means that make you are running is building a new Makefile that you are not running. :-\

Can we remove this from the Makefile.fpc so that this problem goes away. It means you will have to run fpcmake if you make changes to Makefile.fpc but you should be doing that anyway.

The other problem I get, at least in Win32, is convoluted compiler directives from Make. It seems that it compounds the various -Fu and -Fi calls as it goes down through the Make process. Should it do that? I'm not sure if the Linux setup does it, since I haven't been playing with that, but the Win32 sure does. There will be times when it will repeat the whole -gl -Fu..... -Fi..... -d386 sequence 3 times.

The other reason why I think something is a miss in the setup is because of a compile problem. If I do a make from the top level Lazarus directory it will build the LCL and components fine but when it tries to build lazarus.pp it stops when trying to use a synedit unit. Even though the unit is listed in the call and all the synedit files were previously compiled OK it fails stating that it wants to rebuild it but can't find the source.

Now here is the catch. If I go into the LCL directory and do a make it builds the LCL fine. If I go into the components and do a make it builds the components fine. Now if I go to the top level and do a 'make ide' it works and doesn't complain about the synedit file.??????? :-\ :-\ Only if I do a make which equates to a 'make all'

It builds Lazarus for Win32, it crashes but it does at least get built.

I have spent a day and half putzing with this thing, far more time than I have available for this right now. Does ANYONE have a clue as to what is going on?

It's a shame. We have something really nice in Linux and absolutely nothing that we can show in Win32. :-(

You should not. The makefiles for FPC are built manually, and committed. It only means that the makefiles must be rebuilt manually whenever Makefile.fpc changes.

As for the synedit error:
1. Are you sure there is not a synedit unit lingering around somewhere ?
2. Try putting in hints and warnings or -va: Then you should know WHY it tries to rebuild synedit. If it is a compiler bug, We'll need this info.

Michael.

First of all this directory doesn't even seem to exists on the ftp site indicated above.

To be sure I do have the latest I found it AND make_ming_win32.exe on another site and tried both of them and I STILL get the above error.

See the error listed in detail in my next email.

and convoluted. {I have edited onto separate lines for readability.

MAKE.EXE[4]: Entering directory `C:/opt/lazarus/lcl/interfaces/win32' C:/PP/BIN/WIN32/ppc386.exe -dSUPPORTS_RESOURCES
-gl
-Fu.
-Fu./lcl/units
-Fu./lcl/units/win32
-Fu./components/units
-Fu./designer
-Fu./debugger
-Fuc:/pp/units/win32/rtl
-Fuc:/pp/units/win32/paszlib
-Fuc:/pp/units/win32/fcl
-Fuc:/pp/units/win32/gtk
-Fuc:/pp/units/win32/regexpr -Fuc:/pp/units/win32/mysql -Fuc:/pp/units/win32/ibase
-Fuc:/pp/units/win32/opengl
-Fi.
-Fi./include
-Fi./include/win32
-di386
-gl
-Fu./units
-Fu./interfaces/abstract
-Fuc:/pp/units/win32/rtl
-Fi./include
-FU./units
-di386
-di386
-gl
-S2
-Sh
-Fu../../units/win32
-Fu../../units
-Fuc:/pp/units/win32/rtl
-Fuc:/pp/units/win32/paszlib
-Fuc:/pp/units/win32/fcl
-Fuc:/pp/units/win32/mysql
-Fuc:/pp/units/win32/ibase
-Fi.
-FU../../units/win32
-di386
-gl
-S2
-Sh
-Fu../../units/win32
-Fu../../units
-Fuc:/pp/units/win32/rtl
-Fuc:/pp/units/win32/paszlib
-Fuc:/pp/units/win32/fcl
-Fuc:/pp/units/win32/mysql
-Fuc:/pp/units/win32/ibase
-Fi.
-FU../../units/win32
-di386
interfaces.pp

MAKE.EXE[4]: Leaving directory `C:/opt/lazarus/lcl/interfaces/win32'

It appears to be remembering and using previous Make level settings as it goes down in the tree. Again if you call 'make' from the top level of Lazarus on Win32 this is what happens. At least for me. :-)

>Now if I go to the top level and do a 'make ide' it works and doesn't > complain about the synedit file.??????? :-\ :-\

I have sorted this out to some extent by using -va during the compile. The problem seems to rise out of the fact that Lazarus has a file called 'register.pp' AND the fcl has a file call 'register'. Now I didn't look real deep but I am guessing because of the above weirdness with the 'make' call it is finding different 'registry' files at different times during the compile.

As to the windres not building issue. I made sure I had the latest version of make.exe and it didn't act any differently. Here is the exact output from a make call when lazarus.res does not exist. The same command made outside of the make environment works just fine. {line breaks added to make it more readable}

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

Now is this some kind of strange problem with just my setup? I am inclined to think so since Keith doesn't appear to have this problem and he is working with Win32.

I did a clean install to a Win98SE system with the latest Win32 snapshot and a clean checkout of Lazarus and these are the problems I incountered.

Very nice. That will make things much cleaner.

copy of FPC Win32. Make sure you have a run 'make cleanall' and then type 'make' from the top. You will see that by the time it gets down to some of the dependent compilations the options lists are huge.

Another bug I didn't mention was that 'windres' will not run correctly from 'make'. It complains about trying to run GCC. I forget the exact statement. However if I run the exact same command by itself outside of 'make' it works just fine. :-\

I don't think that can be the synedit problem since as I stated depending on how you order the compilation it compiles fine. Also there is the fact that it isn't compiling using GTK. We are doing a straight Win32 API compile on Lazarus with Win32. The reason is that too many GTK items are not supported in the Win32 version. I have downloaded a more recent set of GTK Win32 files and maybe it does support some of the stuff now and we can go back to GTK. I'll let everyone know.

It does exist, but the permissions have changed, probably becasue Peter started packaging the real 1.0.6, but forgot about the FAQ pointing to it

To be sure I do have the latest I found it AND make_ming_win32.exe on another site and tried both of them and I STILL get the above error.

I'll try to make a copy to the contrib dir if I'm home +/- 19:00 CET

From: "Michael A. Hess"

This is a problem with the DJGPP version of make. This error doesn't occur when using the Cygwin version of make
(ftp://ftp.freepascal.org/pub/fpc/dist/win32-1.0.6/separate/makew32.zip).

I'm currently looking at the Makefiles for win32. I hope to finish it tonight. When everything works i'll commit the working versions. The fpcmake changes i wrote about are already finished and working under linux. Only testing them under win32 still needs to be done.

windres requires the preprocessor from gcc, any cpp.exe would be enough. It's a known problem. The best case would to have a resource compiler not depending on other executables.

Peter