On 18 Dec 2013, at 1:42 am, Martin Strubel <hack...@section5.ch> wrote:
> Now for something completely different: > I've been messing around with the build process a few months ago to > enable cross compilation for GHDL. Since you seem to rather have the > global picture in current development, I'd like to hear your opinion > about such a feature (of course, other's opinions are welcome). > Maybe we should open the discussion on another page, but let me quickly > explain the motivation: I sometimes need to hand out a simulation that > needs to co-simulate with something else, both running on a Windows > i386. For convenience, and also to avoid the mcode path, I'm building > all on a Linux box using the mingw32 cross compiler. > Likewise, one could build simulations for a little ARM cluster, question > is, whether such a madness makes sense. > > The cross-support would require: > - Some changes to the build procedure > - Some Path patching in the ghdldrv section (I've added flags like > --AS=... -LD=... to allow specification of the cross toolchain) > - Quite some testing, thus: work :-) > > Currently I've just got an ad-hoc patch for the svn150 variant, but the > full cross compile support would likely require some ./configure > overhead to generate the Makefiles. So maybe -- apart from the cross > funkyness -- it would help the build procedure in general. Sorry if this > has been discussed before (I didn't google up the history..). > > Any thoughts? Ya, thoughts. 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). 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. 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). 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. And should the solution properly fall with in build setup in the gcc build environment you've already seen Brian's and my feeble attempts to at describing how to build the VHDL front end into gcc using configure and make arguments (should you have perused the Wiki). Strictly speaking building on a specific platform is a gcc build issue. ghdl shouldn't preclude building the vhdl language front end from source for compatible gcc platforms. (And you may or may not have noticed the big patch Tristan put in last night including assembler directives for specific platforms, which addresses platform compatibility). I'd personally be concerned that making platform tool selection decisions in the wrong place might preclude ghdl from every being accepted formally as a language front end for gcc. The likelihood of which today is bounded by popularity - driven by language support and features, and compatibility with the gcc build process - including regression or release testing. These two things we can work on. Otherwise we shouldn't be hasty about diverging potentially from 'the one true way' to build gcc. And you'll find the gcc-X.X.X/configure script already contains various 'special consideration' for various platforms. Any reluctance on the part of the gcc developers would likely stem from ghdl not being the 'official' vhdl language front end as well as viability of target platforms. I'd personally suggest taking a top down look before committing to a bottom up solution, which could potentially preclude ghdl from every being an actual part of gcc. And no, I don't think that is all too likely, but if the build process obeys all the rules the gcc developers will tell us what to worry about when, when there are build process changes, instead of reinventing Makefile.in etc., every gcc release. I'd expect llvm comes from the direction of general build process compatibility with gcc, too. There's already been some work in that direction. On the other hand I'd expect platform tool issues to be visible in building the mcode version of ghdl without the gcc compiler build process, along with the issues such as building a 32 bit target with 64 bit tools. (The mcode version of ghdl currently only produces i386 JIT code, or for the adventuresome SPARCv7 code). The answer might properly lie in diverging building the mcode version from the gcc front end version. And a first step to understanding what should be involved is seeing what you've come up with. _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
