Page 5 of 8

Posted: Sun Aug 12, 2012 7:02 pm
by ammianus
Chilly Willy wrote: I use Geany for my IDE... Geany even has a built in terminal so I don't have to open one if I don't want to. If you are using my latest examples that set all paths in the makefile instead of using environment variables, then it's very simple to use this with any IDE - just set the build option to make the makefile... you don't have to worry about environment variables.

Code Blocks has a lot of options for things like environment variables for a project, but I find that all too much for people to deal with. That's why I like simple makefiles with all the paths set in the makefile boilerplate. People really overcomplicate makefiles these days. Just because make allows stupidly complicated makefiles is no reason to actually do so. :lol:
Yeah, I just want to call the same makefile that works for this project. One of the challenges in our case is that we have 2 toolchains in the same project, and it seems like the IDEs assume you would only use one (m68k/sh)

I'll see if I can mold code::blocks to our makefile, otherwise, try out geany, it seems to have the main features I am looking for.

Edit: no luck with c::b so far. I am trying to use geany, where do you put the environment variables from the env.bat? In your user's environment variables? Or is there a way to specify these in the Make command when we call it in geany?

Code: Select all

@Echo Off
SET GENDEV=C:\Users\Documents\roms\homebrew\_gcc\gen
SET PATH=%GENDEV%\bin;%GENDEV%\sh-elf\bin;%GENDEV%\m68k-elf\bin;%GENDEV%\UTILS;%PATH%
SET MAKE_MODE=unix
Cmd "cd" /k
[/code]

Posted: Mon Aug 13, 2012 5:00 am
by Chilly Willy
I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible. So I put all the paths in the makefile. Then the only thing the makefile assumes the path is set for are the host tools like rm or cp. Look at a typical makefile I use now:

Code: Select all

ifdef $(GENDEV)
ROOTDIR = $(GENDEV)
else
ROOTDIR = /opt/toolchains/sega
endif

LDSCRIPTSDIR = $(ROOTDIR)/ldscripts

LIBPATH = -L$(ROOTDIR)/sh-elf/lib -L$(ROOTDIR)/sh-elf/lib/gcc/sh-elf/4.6.2 -L$(ROOTDIR)/sh-elf/sh-elf/lib
INCPATH = -I$./src -I$(ROOTDIR)/sh-elf/include -I$(ROOTDIR)/sh-elf/sh-elf/include

CCFLAGS = -m2 -mb -Ofast -Wall -g -c -fomit-frame-pointer
CCFLAGS += -DHAVE_FFBLK -DDOSISM -DWMODE=0
LDFLAGS = -T $(LDSCRIPTSDIR)/mars.ld -Wl,-Map=output.map -nostdlib
ASFLAGS = --big

PREFIX = $(ROOTDIR)/sh-elf/bin/sh-elf-
CC = $(PREFIX)gcc
AS = $(PREFIX)as
LD = $(PREFIX)ld
OBJC = $(PREFIX)objcopy

DD = dd
RM = rm -f

TARGET = Wolfenstein3D
LIBS = $(LIBPATH) -lm -lc -lgcc -lgcc-Os-4-200 -lnosys
OBJS = \
	src/crt0.o \
	src/id_ca.o \
	src/id_us.o \
	src/id_vh.o \
	src/misc.o \
	src/objs.o \
	src/vi_comm.o \
	src/vi_32x.o \
	src/wl_act1.o \
	src/wl_act2.o \
	src/wl_act3.o \
	src/wl_agent.o \
	src/wl_debug.o \
	src/sd_comm.o \
	src/sd_32x.o \
	src/adlibtables_wsw.o \
	src/wl_draw.o \
	src/wl_game.o \
	src/wl_inter.o \
	src/wl_main.o \
	src/wl_menu.o \
	src/wl_play.o \
	src/wl_state.o \
	src/wl_text.o \
	src/w3dsw_data.o \
	src/automap.o \
	src/debug_32x.o \
	src/debug_font.o

all: m68k.bin $(TARGET).bin

m68k.bin:
	make -C src-md

$(TARGET).bin: $(TARGET).elf
	$(OBJC) -O binary $< temp.bin
	$(DD) if=temp.bin of=$@ bs=2816K conv=sync

$(TARGET).elf: $(OBJS)
	$(CC) $(LDFLAGS) $(OBJS) $(LIBS) -o $(TARGET).elf

%.o: %.c
	$(CC) $(CCFLAGS) $(INCPATH) $< -o $@

%.o: %.s
	$(AS) $(ASFLAGS) $(INCPATH) $< -o $@

clean:
	make clean -C src-md
	$(RM) src/*.o src/*.bin *.bin *.elf output.map
The first few lines allow for one environment variable, and sets the main path to a default if it's not found (and it won't be on my system). Everything else for the cross compiler has a path based on that and the project spelled out in the makefile with no reliance on environment vars. All you do is call make and everything else is handled by the makefile. This is ideal for C::B as all you have to do is set it to a custom make command, and set the command to "make" with the current directory for the command set to where the makefile is.

Posted: Mon Aug 13, 2012 8:45 pm
by antime
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.

Posted: Tue Aug 14, 2012 6:01 am
by Chilly Willy
antime wrote:
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.
What I USED to do is have a text file of all the different exports for each toolchain. Then depending on what toolchain I was using, I'd cut and paste those exports into a new shell since each new shell has only the default environment variables.

Posted: Sat Sep 01, 2012 11:56 am
by ammianus
antime wrote:
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible.
I don't disagree with defining things in the makefile, but you don't have to put everything in your startup environment either. It's easy to create shell scripts for different environments, and any decent terminal emulator will let you create profiles that read the appropriate script on startup. On Windows, cmd scripts and shortcuts can be used for the same effect.

Also, the toolchain will know its "own" library and include paths, you shouldn't have to specify them separately.
Just want to point out that running make from within the available C/GCC/Make aware IDEs doesn't seem to have this flexibility. At least I've been looking for one and haven't really found it yet.

Posted: Sat Sep 01, 2012 12:07 pm
by ammianus
Chilly Willy wrote:I've grown to not like environment variables... mainly because I have so many cross compilers that you simply cannot make environment variables to allow them all to work. It's simply not possible. So I put all the paths in the makefile. Then the only thing the makefile assumes the path is set for are the host tools like rm or cp. Look at a typical makefile I use now:
...
The first few lines allow for one environment variable, and sets the main path to a default if it's not found (and it won't be on my system). Everything else for the cross compiler has a path based on that and the project spelled out in the makefile with no reliance on environment vars. All you do is call make and everything else is handled by the makefile. This is ideal for C::B as all you have to do is set it to a custom make command, and set the command to "make" with the current directory for the command set to where the makefile is.
I see I have it working like that now. Cool, no dependencies on env variables.

I guess I could put the toolchain commands on the system path, the reason I like that better is that running the tools with their explicit full paths results in long output logs when I run make :)

Edit: Works with Geany!

Posted: Sat Sep 01, 2012 8:13 pm
by Chilly Willy
I use Geany the most of the various editor-IDEs... I rather like it. Not too heavy, but still does most everything you want from an editor-IDE.

Posted: Sun Nov 04, 2012 11:44 pm
by ammianus
I don't know if this has already been mentioned in this thread, just a few comments on dependencies. I am trying to rebuild the toolchain on clean install of Ubuntu 12.04.

By default that distro comes with gcc 4.6.3. It is also missing the makeinfo package which is a dependency of the toolchain build. Easy enough to install with sudo apt-get install texinfo. (it's teXinfo, not texTinfo, made that mistake at first). There is another dependency on .7z. But the Archive Manager prompted me to install it automatically.

I also notice there are now newer versions of GMP (5.05) and MPC (1.01) than in the original instructions. Any known pros/cons with using later ones?

Posted: Mon Nov 05, 2012 1:23 am
by Chilly Willy
ammianus wrote:I also notice there are now newer versions of GMP (5.05) and MPC (1.01) than in the original instructions. Any known pros/cons with using later ones?
Shouldn't be. There was a problem with one of the 4.5.x versions with one of those libs where they recommended sticking with an older version of the lib, but I haven't seen a problem with 4.6.x or 4.7.x and the newest version of those libs.

Posted: Tue Dec 04, 2012 7:03 pm
by MintyTheCat
Hello all,

I managed to build a targeted 68K Cross GCC about a Year or so ago. I got Things up and running under Ubuntu.

However, I have decided to manage most of my Tools under FreeBSD.

Has anyone managed to successfully build Chilly-Willy's 68K GCC?

I'm running:
FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

I am building using gmake.

I was going to try a number of different Versions of GCC, Binutils, GMP, MPC and MPFR to eventually zero in on a set of Versions that build correctly.

I tend to subscribe to the Notion of 'safety in Numbers' when using Toolchains so I'm happy to give Chilly-Willy's Build a try.

We all always have such Fun with GCC and Binutils :D

Posted: Tue Dec 04, 2012 8:39 pm
by Chilly Willy
Not sure if anyone has tried BSD before... I guess if you have the dependencies taken care of, it SHOULD work fine. There have been plenty of people who had no trouble in linux, and a few in Windows using CygWin or MINGW... and a couple using OSX. Please report on how it goes in FreeBSD. If you run into any trouble, we can probably figure out what's going on.

Posted: Tue Dec 04, 2012 10:05 pm
by kubilus1
I've built the environment on FreeBSD pretty recently using the scripts from the other build thread (viewtopic.php?t=1248). For the most part this works, but you will have to specify 'gmake' instead of the default 'make' and alter any scripts that specifically specify 'make'. I thought about having MAKE setup as a variable to make this easier in future.

I think I was able to everything setup except one of the tools, 'bin2c' or 'hex2bin' or something, don't remember exactly.

Posted: Tue Dec 11, 2012 11:34 pm
by MintyTheCat
Guys,

I have just moved house from the South of Germany to the North. I shall try building the Binutils and GCC for FreeBSD once I am settled in.

Thanks for the Support.

Posted: Wed Dec 12, 2012 8:10 pm
by kubilus1
I've updated the scripts in my google code project so you should just have to do:

Code: Select all

  $ MAKE=gmake MGET=fetch gmake
I no longer have my old FreeBSD system but will probably setup a VM to try this again sometime soon.

Posted: Thu Dec 13, 2012 2:55 pm
by kubilus1
Alright everything but zasm should work on FreeBSD now. Tested on FreeBSD 8.3. Just checkout the project and do what I recommend in the previous post. This is tested with the gcc and binutils, through the sgdk setup. Since sgdk uses sjasm instead of zasm, you should still be ok.

Now if someone wanted to donate a Macbook Air, I'll take a look at a Mac build on this ... ;)