Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: pozz <pozzugno@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: Improving build system
Date: Thu, 15 May 2025 23:25:03 +0200
Organization: A noiseless patient Spider
Lines: 453
Message-ID: <1005m3f$3aqfb$1@dont-email.me>
References: <vvvq5j$1lml0$1@dont-email.me> <1001m9t$2drv1$1@dont-email.me>
 <100338u$2c42e$1@dont-email.me> <1004all$3218k$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 15 May 2025 23:25:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1f3d99a237d4ce7e6def37ea57ad123b";
	logging-data="3500523"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+UUzxrFtMo95FeuzqBi47a/U4pTytk9k8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:7nTXGAI/gDWNPLRlNde2D0xKA4M=
Content-Language: it
In-Reply-To: <1004all$3218k$1@dont-email.me>
Bytes: 19882

Il 15/05/2025 11:03, David Brown ha scritto:
> On 14/05/2025 23:51, pozz wrote:
>> Il 14/05/2025 11:03, David Brown ha scritto:
>>> On 13/05/2025 17:57, pozz wrote:
>> [...]
>>>
>>> You are asking a lot of questions here.  They are good questions, but 
>>> it would be a very long post if I tried to answer them all fully.  So 
>>> instead, I will try to give a few hints and suggestions that you can 
>>> take further.  I'll put numbers on them in case you want to reference 
>>> them in replies.
>>
>> Ok, thank you very much for your time.
>>
>>
>>> 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.
>>
>> I know, but not all software installers work well if you change their 
>> default installation path.  When it comes to stupid and big IDEs (such 
>> as Atmel/Microchip Studio), I prefer to avoid changing the default 
>> installation path (C:\Program Files (x86)\Atmel...) to avoid other 
>> obscure issues.
> 
> Almost all of them work fine in different directories (and indeed 
> different drives).  First assume they work - only fall back on the 
> crappy defaults if there is no other option.

Yes, you are right.  However I don't think it would be simple to 
understand if a problem is caused by the installation path or other 
obscure reason.  I'm talking about an installation of an IDE (Atmel 
Studio) that takes a very long time to finish.  The installation process 
is a nightmare.


> Of course, the best answer is to avoid any tool made by Microchip - they 
> are the worst of the bunch.  (Atmel was always a bit behind in second 
> place for the title of worst toolchain supplier, but Microchip has 
> gradually integrated them.)  I have many fine things to say about 
> Microchip and Atmel as hardware suppliers, but I make a point of 
> avoiding their microcontrollers because of their tools.

:-)

I worked on PIC8 and AVR8 and IMHO AVR8 is much better then PIC8.
Regarding Cortex-M, SAM devices are fine for me.


> My strong preference - regardless of the manufacturer - is to use the 
> ARM-supplied gcc toolchains (for ARM microcontrollers, obviously) rather 
> than the usually older tools supplied by manufacturers.

It is something I learned.


>> It is already a miracle if that software runs without problems with 
>> the default installation path.  I don't want to imagine what happens 
>> if I changed it.
>>
>> Anyway until now I didn't find issues with spaces.  Even in msys2 
>> shell I can use "/c/Program\ Files\ (x86)/...".
> 
> It usually works - but that does not stop it being a PITA and an insane 
> choice of pathnames.

Sure.


> Still, you have to find what works best for you - I am giving 
> recommendations and suggestions, not a unique solution or single 
> "correct" answer.
> 
>>
>> The other IDE I use is MCUXpresso.  It is Eclipse based so I installed 
>> it in c:\ without any temptations.
>>
> 
> Yes, that has always worked for me.
> 
> (Of course I normally have it on Linux, rather than Windows, and most 
> manufacturer-supplied software uses a sensible default path - in /opt or 
> in /usr/local.)
> 
> 
>>
>>> 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).
>>>
>>> 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.
>>
>> In the beginning (some years ago) I started installing GNU Make for 
>> Windows, putting it in c:\tools\make.  Then I created a simple 
>> Makefile and tried to process it on a standard Windows command line.  
>> It was a mess!  I remember there were many issues regarding: 
>> slash/backslash on file paths, lack of Unix commands (rm, mv, ...) and 
>> so on.  Native Windows tools need backslash in the paths, but some 
>> unix tools need slash.  It was a mess to transform the paths between 
>> the two forms.
>>
> 
> Most tools on Windows are happy with forward slash for path separators 
> as well.  

mkdir, just to name one?  And you need mkdir in a Makefile.


> Certainly everything that is originally a *nix tool will be 
> fine with that.
> 
> Of course if you have a makefile that uses commands like "rm" and you 
> don't have them on your path, and don't specify the path in the 
> makefile, then it won't work.  This is why the norm in advanced 
> makefiles is to use macros for these things :
> 
> # Put this in the host-specific file, with blank for no path needed
> bin_path :=
> 
> # Use this instead of "rm".
> RM := $(bin_path) rm

Initially I insisted using native Windows commands: DEL, MKDIR, COPY and 
so on.  Finally I gave up.



>> After this attempt, I gave up.  I thought it was much better to use 
>> the IDE and build system suggested by the MCU manufacturer.
>>
> 
> For most IDEs, the build system is "make".  But the IDE generates the 
> makefiles - slowly for big projects, and usually overly simplistic with 
> far too limited options.
> 
> But IDE's are certainly much easier for getting started.  On new 
> projects, or new devices, I will often use the IDE to get going and then 
> move it over to an independent makefile.  (And I'll often continue to 
> use the IDE after that as a solid editor and debugger - IDE's are 
> generally happy with external makefiles.)

I'm going to create a new post regarding editors and debugger... stay 
tuned :-D


>> Now I'm trying a Unix shell in Windows (msys, WSL or even the bash 
>> installed with git) and it seems many issues I had are disappearing.
>>
>>
>>> And of course you will want an msys2/mingw64 (/not/ old mingw32) for 
>>> native gcc compilation. 
>>
>> The goal of the simulator is to detect problems on the software that 
>> runs directly on Windows, without flashing, debug probes and so on.  I 
>> increased my productivity a lot when I started this approach.
>>
>> Obviously, the software running on Windows (the simulator) should be 
>> very similar to the sofware running on the embedded target.  Cortex-M 
>> MCUs are 32-bits so I thought it should be better to use a 32-bits 
>> compiler even for the simulator.
========== REMAINDER OF ARTICLE TRUNCATED ==========