Sujet : Re: Improving build system
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.arch.embeddedDate : 15. May 2025, 08:48:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <100467h$3180r$1@dont-email.me>
References : 1 2 3
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 14/05/2025 21:21, George Neuner wrote:
On Wed, 14 May 2025 11:03:56 +0200, David Brown
<david.brown@hesbynett.no> wrote:
1.
>
Windows path naming is insane. Fortunately, you can almost always
override it. Whenever you install any serious program in Windows,
especially if you ever want to refer to it from the command line, batch
files, makefiles, etc., avoid names with spaces or "awkward" characters.
I recommend making top-level directories like "progs" or "compilers"
and putting the tools in there as appropriate. This also makes it
vastly easier to copy tools to other machines. And since you should
never upgrade your toolchains - merely add new versions to your
collection, in separate directories - it is easier if they are better
organised.
Just note that NTFS *does* have a limit on the number of entries in
the root directory of the drive. Offhand, I don't recall what is the
limit [for some reason 127 is stuck in my head] but note that the
typical Windows installation has only about ~20 folders in C:\.
Subdirectories, however, effectively are unlimited.
A handful of extra folders in the drive root certainly will not cause
any problem, but just don't try to install lots of software to
separate folders directly under the drive root.
I am not suggesting that he put all the tools directly in the root folder! But it is a good idea to put programs you want to find in a sane hierarchy. Exactly how any one person wants to organise this will vary - you might want to have IDE's separate from compiler toolchains, and you might want "c:\compilers" to have subdirectories for "arm", "avr", "msp430", or whatever - that's all up to the individual to find the best solution for them.
2.
>
You don't need to use bash or other *nix shells for makefile or other
tools if you don't want to. When I do builds on Windows, I run "make"
from a normal command line (or from an editor / IDE). It is helpful to have msys2's usr/bin on your path so that make can use *nix command-line
utilities like cp, mv, sed, etc. But if you want to make a minimal
build system, you don't need a full msys2 installation - you only need
the utilities you want to use, and they can be copied directly (unlike
with Cygwin or WSL).
A number of common Unix utilities are available as native Windows
executables, so a POSIX environment like msys2 or mingw is not even
needed [unless you want it for some other purpose, 8-) ].
https://sourceforge.net/projects/unxutils/
Indeed, there have been many sources of that kind of program over the years. Most are made as mingw or mingw64 compilations, just like you get in msys or msys2. These days, however, I would recommend msys2 as the easiest and best solution - it has the most flexibility, and you rarely need to be concerned about using more disk space than absolutely necessary.
Of course you /can/ use fuller shells if you want. But don't make your
makefiles depend on that, as it will be harder to use them from IDEs,
editors, or any other automation.
Also note that, on Windows, Powershell is able to launch programs much
faster than CMD. [I don't know why, just that it does.]
Powershell can definitely do some things better than the old command shell. My intention is that a makefile should not be dependent on the shell or environment to run correctly.
(My guess about the speed difference is that the old command shell is probably slower at IO for displaying the output, especially if you have "noisy" builds.)