Re: Baby X is bor nagain

On 25/06/2024 12:15, Michael S wrote:

On Mon, 24 Jun 2024 17:09:25 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

>
(I'm not suggesting Michael change for this project - for serious
embedded work, repeatable builds and consistency of toolchains is
generally far more important than build times.  But I presume he'll
use newer and better tools for new projects.)
>

 It is not that simple.
Tools are supplied by Altera (more recently called Intel, but gossips
are that will be called Altera again really soon now).
Of course, I can build gcc compiler and binutils to native exe myself,
but then it wouldn't be supported. And I'd still will be forced to run
these native tools from cygwin shell because of compatibility with
other vendor-supplied tools.

If that's the vendor-supplied tools, then that's what you use, of course.  I assumed that this was an old project, since gcc 4.1 is a very old version and few people use Cygwin now, and it's normal in this branch to stick to the tools you start with in a project.

Altera/Intel-supplied Nios2 SDK on Windows up to 2018 was based on
cygwin. 2019-2022 it is based on WSL. 2023 and later it is "deprecated"
in theory and removed in practice, both on Windows and on Linux, in
favor of "Nios-V" which is a name for Intel-supplied RISC-V core.
I have a weak hope that if Altera become more independent then the last
step will be reversed, but by now it's what we have.
As you can see, at no point they supported msys/msys2-based tools any
other "native" Windows form of tools.
So practical choice Intel/Altera give is between cygwin and WSL. WSL is
not usable in our working environment. That leaves cygwin.
 

I have customers using WSL for gcc-based builds, though the gcc toolchains in question are mingw64 hosted.  I have no experience with it myself - I use Linux for most development and my Windows system is Windows 7 without WSL.
I used the Nios 2 briefly when it was new, but that was many years ago. I can understand that Altera/Intel are a bit slow with updating the toolchains (and I can understand why they are pushing towards a RISC-V core).  But the Nios 2 is a mainstream gcc port - there is no excuse for them being stuck on such an old version of gcc, and such an awkward emulation layer.

And it's not that bad.
Yes, cygwin shell is inconvenient, but not unusable. Yes, cygwin is
slower. But project that I presented is among our biggest and still a
full rebuild takes only ~15 seconds on rather old hardware. During
development full rebuilds are very rare. More typical build on more
typical project is 2-3 seconds. For me, it's slightly inconvenient, but
tolerable. For few other co-workers it's not even inconvenient. I know
few people for whom it would be quite unnerving, but luckily non of
them is currently doing Nios2 sw development.
 

Fair enough - after all, fast enough is fast enough.
You have no plans of switching to Linux?  I think these days that's the most common OS for FPGA development.  (Of course I am not recommending switching to Linux just to get faster builds :-) )

So, your presumption is wrong. I am going to start new project that
among other things involves Nios2 software and I planning to start it
with cygwin-based build tools. A little newer version of tools (gcc 5.2
instead of 4.1, newer binutils 2.25 etc) but otherwise almost identical
to 11 y.o. SDK that was used to gather numbers in post above.
 

OK.