On 01/07/2010 12:14, Joern Rennecke wrote:
Quoting David Brown <da...@westcontrol.com>:
But it strikes me that a system where the main programs and the plugins
are directly linking to each other is going to make it hard to separate
the development of the two sides, and hard to distribute compiled
plugins that will work with separately compiled main binaries. And
surely it is this sort of separation and modularisation that is the
whole purpose of the plugins?
For the "average" gcc user running Linux and with a single version of
gcc producing native code, it doesn't matter much - they've either
compiled their plugins at the same time as their gcc binary, or (more
likely) their Linux distribution maintainers compiled them at the same
time.
No, both binary plugins and their sources are generally much smaller
than the GCC distribution. And a plugin is built faster from source.
Also, it is often more straightforward to combine different plugins
than to take different patchsets, merge them into gcc sources, and
bootstrap the compiler.
But gcc is far more flexible than that. I use gcc for perhaps six
different targets on a regular basis, with a variety of versions of gcc
for some of the these targets, with different hosts (Windows or Linux),
and with different target OSes (mostly bare metal elf, sometimes Linux,
and some old bare metal coff). To my mind, a plugin that works for
gcc-mips-linux-4.5 should work without recompilation for
gcc-arm-elf-4.6, assuming the same host.
It depends on the plugin. If to uses target-specific macros or types,
(e.g.: FIRST_PSEUDO_REGISTER, CUMULATIVE_ARGS) or invokes functions
specific to a target (could be autoconfigured), then I wouldn't expect this
to work. Also, the name mangling has to match.
I was perhaps over-generalising - obviously anything that depends on
target specifics will be dependent on the target. And I'd also expect
some things to change in the plugin interface between major gcc versions
- while it would be nice to have binary compatibility for plugins
between different major versions of the compiler, I fully understand it
if some things break. The main requirement is that it must be possible
to re-compile the plugin for different gcc versions, but it would be
very useful if re-compilation were not necessary, if such support is not
too costly.
Still, recompiling the plugin for two different gcc builds tend to be much
more lightweight than to rebuild & install two gcc configurations.
True enough.
And it should be possible to
build the plugin binary for Linux, Window s (native/mingw, not just
cygwin) and other major gcc hosts (Mac, BSDs, etc.). Like it or not, a
great deal of cross-compilation embedded development is done using gcc
on windows, and it's a shame if something as potentially powerful as
gcc plugins is not available to those users.
Well, it's their choice (or their employers/sysadmins), we can't force them
to switch to a more powerful development platform. As you said, there are
a number of major gcc host platforms available, and several elf-based ones
run on the same hardware as MS windows.
No, it is often /not/ the choice of their employers or IT folk. I am
the sys-admin for my company, and I also have a lot of influence over
the chips we use and the tools we use for them. But like it or not, a
great deal of tools available are windows-only, and a great many of our
customers and users are windows-only. I fully agree that Linux is a
more powerful platform for /programming/, but for many gcc users there
is more to their daily work (or play) than writing and compiling code.
Many of the tools I use - Firefox, Thunderbird, OpenOffice - are
cross-platform. But for others, such as my electronics CAD software,
it's windows-only.
For many of the bigger microcontrollers, there are development tools
available that run on Linux - very often gcc, perhaps packages with
libraries, debuggers, IDEs, etc, (such as those CodeSourcery makes).
But most non-gcc tools are Windows only, and for most manufacturers, the
only tools they support are on Windows.
For example, when programming Atmel AVR processors the great majority of
developers use Atmel's AVR Studio debugger, simulator, programmer, and
IDE. So most people who use avr-gcc do so under Windows.
In reality, if embedded developers are unhappy (for whatever reason)
with running gcc on Windows, they will move to proprietary compilers
under windows - not gcc on Linux.
Of course, this is not a problem at the moment - gcc plugins are
currently only for particular special purposes and specially interested
developers and users, and so requiring Linux is not a big issue. But as
gcc plugins become more mainstream, it will become a limitation. Should
the famously cross-platform, cross-host, cross-target gcc now be limited
to specific hosts?
