[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Simulavr error

From: Klaus Rudolph
Subject: Re: [Simulavr-devel] Simulavr error
Date: Tue, 22 Apr 2008 09:06:03 +0200
User-agent: Thunderbird (Windows/20080213)

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

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 :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]