Re: Improving build system

Liste des GroupesRevenir à ca embedded 
Sujet : Re: Improving build system
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.arch.embedded
Date : 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.)

Date Sujet#  Auteur
13 May 25 * Improving build system19pozz
13 May 25 +- Re: Improving build system1Nicolas Paul Colin de Glocester
14 May 25 +* Re: Improving build system16David Brown
14 May 25 i+* Re: Improving build system11pozz
15 May 25 ii+* Re: Improving build system4Nicolas Paul Colin de Glocester
15 May 25 iii`* Re: Improving build system3David Brown
16 May 25 iii `* Re: Improving build system2Nicolas Paul Colin de Glocester
16 May 25 iii  `- Re: Improving build system1David Brown
15 May 25 ii`* Re: Improving build system6David Brown
15 May 25 ii `* Re: Improving build system5pozz
16 May 25 ii  `* Re: Improving build system4David Brown
16 May 25 ii   `* Re: Improving build system3pozz
16 May 25 ii    `* Re: Improving build system2David Brown
16 May 25 ii     `- Re: Improving build system1pozz
15 May 25 i+- Re: Improving build system1David Brown
16 May 25 i`* Re: Improving build system3pozz
16 May 25 i `* Re: Improving build system2David Brown
17 May 25 i  `- Re: Improving build system1pozz
14 May 25 `- Re: Improving build system1Stefan Reuther

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal