Re: [Simulavr-devel] Simulavr error

[William Rivet]

lol! 

Ok everyone. Plutonium is bad...I can't figure out how to get autotools
to behave as anything other than that...perhaps I'm just dumb in this
area or just didn't devote enough time to understanding all the bits...

So..Klaus has a set of makefiles. I'd be happy to have them in and
explained how to use in a README. 

I think Klaus (and others) are 100% correct to say this is for
developers, they should be able to figure out how to "fix" a makefile or
conif.h file. 

Having said that, I'm not satisfied with this as the only solution...so
I'll tinker with CMake and check it in soon. I'm reworking the python
version of the sample to be python only, then I 'll check in. This will
have little effect on this whole conversation if you are happy with the
makefile based build. On the other hand, some may fine CMake beneficial
in producing non-make based build. (I don't know, I have not tried this
aspect of CMake yet...and may be another source of plutonium!)

So...autotools are out...Klaus' makefile is in. CMake is experimental
for some time to come, and after I get about 3 more hours to spend in
this, I'll checkin what I have. (including Klaus' makefiles, if he
hasn't already done this)

As for packaging, I'll stay out of that for now. Anyone willing to take
on that task have my ear though!

Cheers,

Bill




On Wed, 2008-04-16 at 11:12 -0400, Michael N. Moran wrote:
> Klaus Rudolph wrote:
> > Michael N. Moran schrieb:
> >> I understand all sides of the issue ...
> >> 
> >> Software developers (especially embedded software 
> >> developers) should be comfortable with using make.
> >> 
> >> I hate autotools, however, they are ubiquitous in the 
> >> free software world, and having yet-another system for 
> >> accomplishing the same thing (e.g. CMake) does not 
> >> sound like a "good thing."
> >> 
> >> OTOH, the one who volunteers to do the work SHOULD get 
> >> the majority vote :-)
> >> 
> >> 
> > Lets finish all the discussions... what is actually 
> > required from the "outside world"?
> 
> A reliable familiar way to build simulavrxx. :-)
> 
> e.g.
> 1) unpack (eg tar xzf)
> 2) configure (./configure)
> 3) make
> 4) make install
> 
> > As I said: "My" simulavrxx is running fine on multiple
> > unix systems. What is needed from the others??? What can
> > I do now to get your problems solved?
> 
> As I understand it, William Rivet is working on
> *a* solution, so I don't think you're being asked
> to do anything.
> 
>