Hi Przemek,
Windows in general) was and still - after 10 years -
is such a PITA to work with.
I haven't made any real Windows builds for very long time
but AFAIR it was very easy to setup MinGW and MSYS environment.
You have to sets of GNU tools one designed for MSYS and 2-nd
for Windows command shell. It was enough to keep them in default
paths and when you want to use MSYS then simply set MSYS binary
directory at the beginning of your PATH. Otherwise do not set it
at all or set it at the end.
That's all and it was working for me.
Okay, I've checked all my m* dirs and there turned out
to be some leftovers from the past, so I'm currently
testing the cleaned environment. There are a few
strangenesses still, like missing make.exe from mingw,
even if I select this option. (The .exe is named mingw-make.exe),
but anyway, I have a mingw based make.exe in the path
anyway, so this is still hacky, but fine. I dropped msys
from the path for Windows shell builds.
For bash shell builds (which I'll use for 1.0.0 binaries),
I've added msys to the front, and cleaned my bin dir
from some past make.exe versions copied there (it was
also a mingw make.exe).
This way it looks clean and tidy, with only one hack
(make.exe in the path).
And to rumble a bit more: GNU make is probably the
far weakest piece of the GNU toolchain, I can't even
understand how it didn't get a replacement in all
these years.
I do not agree. What is missing for you in GNU make?
For me it's the best make tool and when I have to use
some other then I still found some limitations. Maybe
I do not know those tools enough but as I can see some
things cannot be easy resolved also i our non GNU make
files what effectively blocks their simplification.
It cannot pick sources from different dirs and/or
cannot put target into different dirs. I can't remember,
but each time I have to deal with GNU make, I end up
spending days on it without any results.
The other thing is this insane reliance on TAB vs. spaces.
Other thing is _OUR_ GNU make files. It should be seriously
changed but because it has to work on all supported platforms
then I try to not touch it as long as possible.
Somewhere in the future I'll try to change it but without any
deadline because all modifications will have to be tested in
many different platforms and environments.
Hm, yes. I don't know what exactly you have in mind,
but for me for example the way recursivity is solved
seems rather problematic, error prone and slow. It
starts to have lots of hacks too.
I still believe we should be better off with one
make system, which is working perfectly well everywhere,
rather than having GNU and 3 non-GNU build paths.
This one make system can be GNU, I have no problem
with that, I'm just unlucky with it locally.
[ Okay, some say that having native build environment
is always good - which I can agree -, but the overall
importance of BCC and even MSVC is fading year by year. ]
Anyhow, anyone who managed to tame MinGW in a
proper way, is welcome to share his experiences,
and best practices.
Today I'll try to make some tests with real MS-Windows machine.
Maybe I'll find some problems which appeared in last year(s).
Thanks, I'm sure you'll find some things to fix :)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
