Hi all,
I also however know that libbfd is a pain for us the way we use it
becuase over time it changes in ways we often don't care about, but
cuases trouble for our simulavrxx users who have to cause it to be built
and installed...then simulavrxx has to find and use it x-p
There has nothing changed which was a problem for simulavrxx. The only
trouble comes from mixing headers with different libs.
I'm pretty sure one of my build clean-up activities should include just
including a suitable version of libbfd sources in simulavrxx
Oh no! We have discussed that a lot of times and I will not include any!
sources from foreign projects. Not TCL/TK and not libbfd. There is no
reason for it! The only problem is that we have the corresponding bfd.h
with the libbfd compiled for avr. Nothing more must be fulfilled.
For a gcc test suite simulavrxx and simulavr are nearly the same. The
decoder uses the same instruction set (sleep is not supported, but this
instruction will not be part of any standard c code and also writing
flash is not inside, but this is not what the compiler is interested in:-)
I have not understood why we need a reduced smaller simulavrxx for a
test suite? Is the size a problem?
Back to the point of build tools:
Bill had done a lot for building the tool on different plattforms and a
lot of searching all the dependencies. But all that work results
actually in a very complex build system. As Knut allready mentioned, we
actually have a build tool chain which must have python to build the tcl
examples. That sounds very terrible for me and makes things much to
complex.
From my point of view:
I use my own old Makefile with one config file which contains 2 lines of
informations: path to libbfd and path to tcl/tk. Thats all. No need for
any! kind of external tooling (autotools) and so on. Making things
"automated simple" could result in complex results :-)
For a gcc test suite there is also no need for having tcl/tk or python
or any other scripting language available. Simply read the elf-files and
watch the results of simulation with some environment for automation. If
there is a need for a more elaborate solution: let me know! Maybe I can
do that for you!
Bye
Klaus
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
