GNU make 4.2
I got GNU make 4.2 compiling under SAS/C.
I've done some initial testing with my usual projects and it seems to work nicely.
https://github.com/dmcoles/gnu_make_amiga/releases/tag/4.2-05032024
The latest version I've seen around before is 3.82 which is quite some years older.
Sadly they made some major restructuring in 4.3 and 4.4 which have made it
much more difficult to build those versions on SAS/C.
I haven't extensively tested it - so i'm not releasing it to the aminet yet but it seems to
work ok with my own projects. Please do feel free to feed back.
I considered rewriting EBuild with my new filter features on the framework for EEC but who would use a custom make replacement? It reeks of not-invented-here syndrome but what choices do we have? Meson requires Python 3.7, Ninja build is needed only for its intelligent thread-pools and requires a higher level construct like CMake or Build Ninja for common use, Jam is only used by Haiku and Perforce, what other build systems are there?
i've also now managed to get 4.4.1 building on SAS/C
Which you can download here:
https://github.com/dmcoles/gnu_make_amiga/releases/tag/4.41-06032024
Hi Darren,
I'm using your 4.4.1 make build for my projects but I get weird things when trying to pass variables to sub-makefiles.
* variables created in the main makefile are not passed to the sub-makefile, even when exported,
* using -E to pass a variable definition to the sub-makefile seemed to work but all of a sudden, it didn't anymore,
* environment variables created for testing are not read correctly, I mean it's listed but it has no value.
For testing I use this simple makefile instruction:
$(foreach v, $(.VARIABLES), $(info $(v) = $($(v))))
Then I set a variable in a shell, eg. setenv TST OS3
and I try to read it in make variables
make | grep TST
Can you please give it a try to see if it's reproducible ?
My System version is 3.2.3, Amiga 500 with Firebird accelerator.
TIA,
Olrick.
Hi,
I did some tests, trying UAE to get rid of hardware doubt, trying previous versions to check environment variables management and finally reverted to make 4.2.1 which seems to be OK up to this point.
can you provide detailed instructions / files to recreate this and i will take alook
Hi Darren,
Open a CLI,
create a makefile containing the line :
$(foreach v, $(.VARIABLES), $(info $(v) = $($(v))))
set a dummy environment variable, eg.
setenv TST OS3
and call make, it should list all variables, including environment ones, but in my case, environment variables are displayed empty, eg.
TST =
I inspected make sources from versions 3.75, 3.76.1 and 4.41, to see if something looks subject to error, but I didn't notice any evidence. I just got SAS/C 6.58 sothat I can try building make 4.41 and debugging my problem.
If you have any advice on building, it would be great, as the last time I used SAS/C, it was still Lattice C... ;)
Thanks for helping
Getting it building if you have a working sas/c setup should be quite simple. It also needs a working copy of make and then it's just make -f Basic.mk
Debugging it though is a different matter. It's a pretty complex piece of code which I don't claim to even begin to understand.
I'll happily take a look though and see what I can figure out
Building is not that easy. I already tried using Basic.mk as the readme says, but it does not call amiga.mk which will put in place the config.h for amiga.
I have to analyze the buid chain to understand it.
as far as i can see none of the native versions compiled with SAS/C have working versions of this.
Theres amiga specific code that adds in all the variables from ENV: with a blank value and this comment:
/* Define an empty variable. It will be filled in
variable_lookup(). Makes startup quite a bit
faster. */
but there is no variable_lookup() function and the lookup_variable() function does not have anything in there to handle it.
I have added a quick and dirty fix which seems to work for me:
https://filebin.net/wlbqkgwlxig5dhhx
give it a go and let me know
Hi Darren,
It works here too, I get environment variables. I will check if it solves the problem with my sub-makefiles.
I made some progress about building make, well, about understanding what is required to make it work, as different versions of Amiga make behave differently, especially for path management and MAKE_HOST definition.
Out of the box, your 4.41 version fits the best with its own build chain. Too bad I just noticed that after hours playing with 3.82 version. The benefit is that I have a much better understanding of make processing and ways to debug makefiles.
Thank you for the quick fix.
Hi Darren, Variables are still not exported to submakefiles. Here is my test sample:
5.Files:Dev/C/Tests/make/sub
> dir all
lib (dir)
makefile
makefile
5.Files:Dev/C/Tests/make/sub
> type makefile
PETUNIA := $(shell version petunia.library)
ifeq "$(word 1,$(PETUNIA))" "petunia.library"
export OS := OS4
else
export OS := OS3
endif
ECHO := echo
.PHONY: all lib
all: lib
@$(ECHO) Done.
lib$(warning OS = $(OS)):
$(MAKE) -C lib all
5.Files:Dev/C/Tests/make/sub
> type lib/makefile
$(warning OS = $(OS))
ifeq "$(OS)" "OS3"
CC := vc
else
CC := gcc
endif
ECHO := echo
.PHONY: all
all$(warning CC = $(CC)):
@$(ECHO) Lib done.
The execution reveals that the OS variable is not transmitted:
5.Files:Dev/C/Tests/make/sub
> make
Makefile:14: OS = OS3
make -C lib all
make: Entering directory 'Files:Dev/C/Tests/make/sub/lib'
Makefile:1: OS =
Makefile:11: CC = gcc
Lib done.
make: Leaving directory 'Files:Dev/C/Tests/make/sub/lib'
Done.
I would guess this is a different issue. I will take a look
Hi.. this took a bit longer than expected. The Amiga port didnt have any capability for passing variables to sub makes.. i have managed to implement this now
You can grab my 4.4.1 build of make with this functionality here
https://filebin.net/9o5dzz8qgy96owji
Hope that helps
Online Status
Just browsing through the git repo for gnu make and I notice that all Amiga support was removed from the code just after the 4.4.1 release about a year ago. So even if we manage to get the new build system in 4.3 working then we can at best get updates 4.3, 4.4 and 4.4.1 and then we would not be able to get any further updates without reinstating all of the removed code