Hi David, > > Collectively I refer to these as 'Who Bells the Cat?' after snarky things > Robert Heinlein used to put in some of his novels about nice ideas and who > does the actually work (a pun about division of labor). >
I didn't speak up before to just not create work. I just made it work for me as an experiment. So if everyone thinks: Bullocks, won't need that, it's not worth all the ./configure'ize effort, I think. > If you look in the gcc-X.X.X/vhdl subdirectory for the ghdl supplied VHDL > language front end you'll find various configurable files use in building the > ghdl front end, config-lang.in, lang.opt, Make-lang.in and Makefile.in. > There's also lang-specs.h and lang-options.h. These are all produced along > with the appropriate Ada and C source code from the ghdl source distribution. > > They are used to communicate how to build the ghdl front end to the gcc build > process. You'll notice none of these specify tools used to build the ghdl > front end to gcc until you hit Makefile.in where yo'l find bindings for > macros MAKE, MV, RM, RMDIR, ECHO, LN, CP, AR, MKDIR, CHMOD, true, pwd, and > cd, which are all apparently required. > I've taken the book approach first, but found out it's not just done with the ./configure --target=$CROSS dance. If I remember right, it turned out in the ADA code being compiled for the cross target. > So the question is whether or not specifying linkers and assemblers belongs > in these, and I'd be inclined to think not. The commentary at the beginning > of Makefile.in tells the story. (There's also this process model of asking > yourself the question as to why Tristan doesn't have the facility for doing > so already expressed). > The LD and AS spec to ghdl_gcc I hacked in should definitely be revisited. But it appeared to me that, since cross-compiling support was not in there, they were hardcoded in translate/ghdldrv/ghdldrv.adb to 'as' and 'gcc'. For the proper cross ghdl, it would make sense to use the machine prefixes for as/gcc. > I'm more inclined to believe the proper place for specifying build chain > tools is through gcc-X.X.X/configure, etc. And likely it should be a matter > of configuration. > > My first inclination is that if you have the urge to put specific tool > information in source provided by ghdl that there is likely some confusion > over multistage builds. And I could be wrong, I'm far from being a current > expert on building gcc. > > The point of all this is that I wouldn't (personally) make a rush to > judgement on accepting the content of your patches to cross compile without > looking at the issue from a gcc perspective. As Brian has pointed out in the > past, there are usually three ways of doing something when building gcc. > (Funny, I can only usually find two). It's likely a top down gcc issue and > not a bottom up from ghdl issue. > Nope, this should be taken very slow, as the patches are currently kinda dangerous matter. But as a first approach, I'd have tried to prototype a separate ./configure procedure the 'bottom up' way, just to get ghdl built against existing cross toolchains (the 'Compiling for development' approach from the README). Then, the right 'upstream' solution should definitely be the gcc top down compatible one, I absolutely agree about that. So I'd try see if I can get an isolated build environment ready that builds against a working cross toolchain setup, then see if it's worth the effort to implement that in a full GCC build. This would still require multiple passes in a sandbox, I'd presume. Like: - Build native GCC/gnatmake, etc. with ADA support - Build cross GCC and libraries (mpc, mpfr, ...) with the vhdl lang option But more later... Greetings, - Martin _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
