Joerg Wunsch schrieb:
As Klaus Rudolph wrote:
Build it with MinGW / MSYS so Windows users can use it....
Like to hear that :-) But I have no windows system running since now
more than 10 years.
But it's a legitimate request to have at least a flexible enough build
system around to accomplish that kind of task, even if it's not /you/
who's going to do the porting. (I can fully understand your
sentiments about Windows, I don't want to be plagued by that myself.)
You are right. It would be nice to have all the build tools running, but
we are struggled with the autotools.
Porting to windows should not be a big deal. As I know the only OS
depended thing is the socket connection. All other things should run out
of the box. Maybe there are some special header file deps which must be
solved... but if there are problems: please ask! As already said: I will
support any technical question :-)
Frankly, I doubt a couple of thrown-in Makefiles would accomodate more
than one or two mainstream Linux distributions, it'll likely already
stumble when compiling on *BSD (so far, I never ran through completely
there, there's always been something missing), let alone MacOS X or
Solaris.
And no, AVR developers are a different class of developers than host
system developers, so the expecation that they might fix the Makefiles
for their respective system won't be met in practical life.
Nobody must take a look into the makefile itself. The only manual thing
which must be configured is the path to avr-binutils build directory and
the tcl stuff. This information is placed in one config file. After
that, simply type make and the tool is ready to use. If this is not
working somewhere... please ask! (Not on windows... see above :-)
Personally, I'm everything but a big fan of the auto* tools (mainly
due to their upwards compatibility issues), but I still believe
they're something like the least common denominator for a flexible
enough build system.
Yes, I agree. It would be nice to have one package which runs on every
os. But there is no one which is able to do the job in the moment :-( If
there is any help available, we will listen for it! :-)
To avoid users being plagued by the idiosyncrasies of the auto* tools,
just prepare frequent releases which have the auto* tools run on the
user's behalf, so the user only has to run ./configure. So far, there
have been four releases of simulavrxx within reasonably tight sequence
(less than a year) almost three years ago, and silence ever since.
This doesn't give anyone a feeling the software were being maintained
at all when looking onto the project from outside.
Actually there is now grow in simulavrxx, right. But all technical
questions are answered from my side. I have no running projects for
atmel in the moment so I have no need to increase the tool. So the
actual situation is that the tool is supported but is not growing. And a
windows support is welcome if there is one :-)
Bye
Klaus
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
