[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Grant Edwards <grante@visi.com>]

In gmane.os.ecos.general, you wrote:
>>> I believe I'm seing the same segmentation fault.
>>>
>>> Did you find a way to resolve this problem?
>>
>>Sort of:  Use Linux.
>
> Cheat! :-)
>
>>> My first thoughts was to try to revert to an older GCC version for
>>> CygWin or worst case attempt a cross-build from Linux.
>>
>>I just switched to Linux.  Once I get everything else ironed
>>out, I'll mess with Cygwin again (assuming my client really
>>wants me to).
>
> I disabled precompiled headers while configuring the toolchain. That
> did the trick.

How did you do that?  I couldn't find any "configure" options
that mentioned precompiled headers.

>>Building eCos for NIOS2 is the biggest mess I've ever seen: A
>>Shell script wrapper for a Java program that generates a CDL
>>file that generates a shell script that generates a Perl script
>>that calls a Java program that generates include files, etc.
>>etc.
>>
>>What a pile.
>
> I don't know why Altera thinks it needs to be that way.

They seem to be real big on the theory that you should be able
to sit down at a GUI click a few times to configure hardware,
click a few times to build software, and you're done.  It works
fine as long as you want to build something they've already
thought up and pre-configured, but the second you want to build
something that isn't one of the included demos, the whole thing
collapses of it's own weight.

Even if you do manage to click on enough of the right things
in the right order to build eCos and an eCos application,
there's no way you can document and automate the a build
procedure so that you've a hope in hell of being able to build
the same thing next week or of the guy in the next cube being
able to build the same thing this week.

> Though I can see how a soft-CPU with a dynamic number of
> peripherals would be a poor impeadance match with eCos static
> cdl files.

There's sure got to be a better way to deal with it than what
they've got now.  It's taken me a lot head-banging to get to
the point where I've got a shell script that can repeatably
configure and build RedBoot from the command line.

Now I've got to figure out what portions of the NIOS tree has
to be archive along with the eCos source tree to provide the
input files that are needed to create all of the CDL files on
the fly.

> I never quite understood why eCos considers a specific HAL
> part of eCos.

It sure would be a lot easier to manage if the HAL was separate
from the main eCos tree.  Have a huge tree of "off the shelf"
stuff with one modified file and one buried directory of
"custom" stuff is a real PITA to manage in a production
environment.

> I always viewed the HAL as part of the application.

I would go that far.  We build a lot of different applictions
all based on the same target board and eCos/HAL combination.
Still, it would be a lot easier to manage if the HAL wasn't
mixed in with the "generic" stuff.

> Although final PCB's might strongly resemble a particular
> evaluation board, I wouldn't expect it to be exactly like the
> evaluation board in the general case. Never happened to me
> anyway. The stuff that can be shared between HALs and that
> does not change between HALs seems to belong(as in making the
> whole shebang more easily maintainable) in eCos.
>
> BTW, at first glance I couldn't even find eCos in the Nios2
> 6.0 beta.

It's buried pretty deep.

-- 
Grant Edwards                   grante             Yow!  .. I want FORTY-TWO
                                  at               TRYNEL FLOATATION SYSTEMS
                               visi.com            installed within SIX AND A
                                                   HALF HOURS!!!

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss