Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Tue, 25 Jun 2024 13:15:20 +0300
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <20240625131520.000007b1@yahoo.com>
References: <v494f9$von8$1@dont-email.me>
	<v49seg$14cva$1@raubtier-asyl.eternal-september.org>
	<v49t6f$14i1o$1@dont-email.me>
	<v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
	<v4bh56$1hibd$1@dont-email.me>
	<v4c0mg$1kjmk$1@dont-email.me>
	<v4c8s4$1lki1$4@dont-email.me>
	<20240613002933.000075c5@yahoo.com>
	<v4emki$28d1b$1@dont-email.me>
	<20240613174354.00005498@yahoo.com>
	<v4okn9$flpo$2@dont-email.me>
	<v4p37r$k32n$1@dont-email.me>
	<v4pei3$m5th$2@dont-email.me>
	<v4plsk$nn9o$2@dont-email.me>
	<v4pnq6$o4fs$1@dont-email.me>
	<v4q245$si2n$1@dont-email.me>
	<v4q2rl$sqk3$1@dont-email.me>
	<v52308$2nli8$3@dont-email.me>
	<v53i4s$33k73$2@dont-email.me>
	<v53lf7$34huc$1@dont-email.me>
	<v53vh6$368vf$1@dont-email.me>
	<v54se1$3bqsk$1@dont-email.me>
	<20240624160941.0000646a@yahoo.com>
	<v5bu5r$va3a$1@dont-email.me>
	<v5c275$vq9k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 25 Jun 2024 12:15:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="005d77a9345c902387ac819a516a3997";
	logging-data="1547383"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/bwdN4KgTQ5a53uUt3b532JQnwS7wuwD4="
Cancel-Lock: sha1:fiLxBCcninjYNH/Gl3d+MiW7Oi0=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4093

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.
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.

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.

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.