From: Bernhard H. <ber...@be...> - 2003-04-22 20:01:56
|
> Here is what I meant: > - In case of mingw (if the value of --host includes mingw32), > default values should be: > prefix=\sdcc > datadir=\sdcc > - In case of *nix, including cygwin, default values should be: > prefix=/usr/local > datadir=/usr/local/share > > so that invoking ./configure without parameters will generate *nix version > of sdccconf.h, > invoking ./configure --host=i586-mingw32msvc will generate mingw version of > sdccconf.h. What a weekend ... first I wanted to implement your proposal, even if I've a slight different opinion. I don't want to disappoint you, you're doing a great job supporting the windows platform. And this is important, because the postings in sdcc-user clearly show that many, many users run the windows binaries. I guess they are even the majority. But when I started to implement the necessary changes I remembered why I stumbled and hesitated already the first time. I thought it's not possible to cleanly implement it, and I did it without switching defaults. After this I started to write this reply and explained, why I did it my way. Doing this I had to recognize, that I was wrong: a clean implementaton is possible. But I was out of time and now I thought two more days about the problem. Today I'm convinced, that 'configure' shouldn't switch defaults. It would be "schizophenic", and this would cause more confusion than it could help. 1. In the autoconf macros there's nothing assigned for switching the default paths. It's seems, that it's absolutely not intended to do something like this. 2. Somebody, who's used to 'configure', has a clear expectation, what 'configure' is doing. He/she would certainly _not_ expect, that all the default paths change with magic keywords in "CFLAGS" resp "host". He/she would have to have a deep look in the documentation, what items are changing and what not. 3. An unexperienced 'configure'-user would be confused too. 'configure' together with 'make' are very powerfull, if the options and/or environment variables are used. This is a complex setup, and it's not easy to get a survey at the first or even second sight. The confusion would be perfect, if everything changes with a little keyword. I saw even in one of your posts "Wrong BIN2DATA_DIR", that you doesn't seem to fully understand 'configure'. I know, 'configure' didn't behave consistent at that time, and you had a different expectation of what is already implemented. But that's exactly the problem: if the switch is under the hood, you'll never know what's going on. Therefore: 4. You can easily change all 'configure' paths with options and/or environment variables. That's the way it was designed for. All we've to do is to write a little script, which passes the parameters to 'configure'. Even with a shizophrenic 'configure' we would need ~3 params (CLFLAGS, LDFLAGS, --disable-ucsim), for which it would make sense to use a script. With a straight forward 'configure' we need only 6 additional parameters to make the switch to mingw32 host. 6 parameters are nothing compared to the additional effort in 'configure.in" and the lenghty explanations in sdccman.lyx. The pro and the beginner can see at first sight, what's happening. We'll put the script in CVS and in sdccman.lyx, so nobody has to reinvent the wheel. I hope this will convince you. If I'm wrong, or if somebody has better arguments, please tell me. I'm also still new to autoconf, and I've certainly also to learn more about it. > The problem is also the difference in mingw cross compilation on *nix and > cygwin: > - on *nix the gcc cross-compiler is executed > - on cygwin the standard gcc compiler with -mno-cygwin is executed > So we have to have a way to tell configure, which of two it will use. > One option is to define -mno-cygwin in CFLAGS and LDFLAGS (the way it > currently works), > the other would be to define a special host > (e.g. --host=i586-cygwinmingw32msvc). > I would vote for the second one (if it is feasible). Both WAS implemented. > > Hnnngh. That's what I was already working for :-( Without my changes to > > the usage of CFLAGS, LDFLAGS, ... you won't have succeeded! > > But it works! The command line is: > ./configure CFLAGS="-mno-cygwin -g -O2" LDFLAGS=-mno-cygwin Yes, I know ;-) Look at ChangeLog entries from 2003-04-12 and 2003-04-07 (bug fix 487815). Bernhard |