Giter Site home page Giter Site logo

dmbs's Introduction

DMBS - Dean's Makefile Build System

Project Overview

GNU Make is scary, and it's tough to get the rules right sometimes. Many projects get by via simple copy-pasting of old makefiles, resulting in many redundant copies of the same old rules. DMBS aims to solve this by providing a simple modular set of makefiles which can be included by your project to quickly add various build functionality.

This aims to replace the old WinAVR "mfile" makefile template, giving better functionality and much simpler user makefiles.

Benefits:

Apart from much simpler, cleaner makefiles DMBS carries the aim of making the process of troubleshooting build issues a little easier. Lots can go wrong, so DMBS tries to sanity check its inputs wherever possible, and produce human-readable error messages. Forgotten to set a variable? Get a Makefile {X} value not set. message, rather than a possibly unrelated message. Have the wrong filename? See Source file does not exist: {X} rather than the infamous No rule to make target {X} message.

Use:

A template user makefile is provided in the Template directory. DMBS modules are included via a GNU Make include directive. While the DMBS core module is always required, you can pick and choose what other modules you wish to add to your user project.

See here for the documentation on the individual modules provided by DMBS. If you're interested in writing your own DMBS module(s), see here.

Here's an example user makefile:

MCU          = atmega128
ARCH         = AVR8
F_CPU        = 8000000
OPTIMIZATION = s
TARGET       = Template
SRC          = $(TARGET).c
CC_FLAGS     =
LD_FLAGS     =

# Default target
all:

# Include DMBS build script makefiles
DMBS_PATH   ?= ../DMBS
include $(DMBS_PATH)/core.mk
include $(DMBS_PATH)/gcc.mk
include $(DMBS_PATH)/cppcheck.mk
include $(DMBS_PATH)/doxygen.mk
include $(DMBS_PATH)/dfu.mk
include $(DMBS_PATH)/hid.mk
include $(DMBS_PATH)/avrdude.mk
include $(DMBS_PATH)/atprogram.mk

Each DMBS module can optionally supply one or more Make variables and macros, which you can reference in your user makefile. Additionally, modules can require one or more variables to be set by the user makefile, with (in some cases) sane defaults used if left out.

As modules are added, you can get a list of available targets by simply typing make help from the command line. This will produce a formatted list of targets as well as mandatory and optional variables and exposed variables and macros.

Distribution

You can embed DMBS in your project any way you like - some options are:

  1. A git submodule
  2. A source tarball
  3. A manually copied extracted archive

The intention of DMBS is that users can just import it from whatever source they like. If your project needs to extend the existing modules in an unusual manner, or if you want to provide your own modules, you can include them in your project repository (or submit a patch to DMBS if your module is generic enough to warrant wide use).

License

DMBS is released into the public domain, making is suitable for use everywhere, by everyone. Contributions are greatly appreciated however, in order to make DMBS better for everyone.

The actual license text is as follows:

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit
of the public at large and to the detriment of our heirs and
successors. We intend this dedication to be an overt act of
relinquishment in perpetuity of all present and future rights to this
software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <http://unlicense.org/>

dmbs's People

Contributors

abcminiuser avatar dudanov avatar jacquesg avatar moscorep avatar nicohood avatar schlumpf avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dmbs's Issues

OBJDIR default

I made two projects, both using a common library file:
SRC = $(TARGET).c ../libs/bbuart/BBUart.S

When I build project1 then project2, it creates ../libs/bbuart/BBUart.o each time.
When I modify target.c and rebuild project1, it just relinks BBUart.o that was built with the options for project2.

My solution was to modify gcc.mk so OBJDIR defaults to objs. This way each project directory has a separate copy of BBUart.o, built with the project-specific options.

Add macros to CORE to test and enforce minimum DMBS version

Module extensions (and perhaps user application makefiles) using DMBS might want to enforce a minimum DMBS version.

Need to add some macros (ENFORCE_MINUMUM_DMBS_VERSION perhaps?) which the user makefile can use, to check and ensure that a minimum DMBS version is met, otherwise report an error.

Add Module Template/Sample

This text is quite informative, but still not enough if you ask me:
https://github.com/abcminiuser/dmbs/blob/master/DMBS/WritingYourOwnModules.md

I am currently working on a whole DMBS setup for libraries etc. My template looks like this:

# Include Guard
ifeq ($(findstring TEMPLATE, $(DMBS_BUILD_MODULES)),)

# Sanity check user supplied DMBS path
ifndef DMBS_PATH
$(error Makefile DMBS_PATH option cannot be blank)
endif

# Location of the current module
TEMPLATE_MODULE_PATH := $(patsubst %/,%,$(dir $(lastword $(MAKEFILE_LIST))))

# Import the CORE module of DMBS
include $(DMBS_PATH)/core.mk

# This module needs to be included before gcc.mk
ifneq ($(findstring GCC, $(DMBS_BUILD_MODULES)),)
$(error Include this module before gcc.mk)
endif

# Help settings
DMBS_BUILD_MODULES         += TEMPLATE
DMBS_BUILD_TARGETS         +=
DMBS_BUILD_MANDATORY_VARS  += DMBS_PATH
DMBS_BUILD_OPTIONAL_VARS   +=
DMBS_BUILD_PROVIDED_VARS   += TEMPLATE_SRC
DMBS_BUILD_PROVIDED_MACROS +=

# Sanity check user supplied values
$(foreach MANDATORY_VAR, $(DMBS_BUILD_MANDATORY_VARS), $(call ERROR_IF_UNSET, $(MANDATORY_VAR)))

# TEMPLATE Library and stream cipher modes
TEMPLATE_SRC := $(TEMPLATE_MODULE_PATH)/src/lib.c

# Compiler flags and sources
SRC			  += $(TEMPLATE_SRC)
CC_FLAGS 	  += -I$(TEMPLATE_MODULE_PATH)/include/

# Phony build targets for this module
.PHONY: $(DMBS_BUILD_TARGETS)

endif

usage recommendation

How do you recommend using dmbs?
I've used git submodules.
I see for lufa you copied dmbs, prefixing most of the variables with lufa_. This would seem to make it hard to incorporate improvements to dmbs into lufa.
Another option would seem to be forking and modifying the template.
Perhaps the readme could include a recommendation or list of options.

build vars dependency?

Looking at gcc.mk, I couldn't find a dependency for build vars or the makefile itself. If, for example, F_CPU is changed, will the target get rebuilt?

small refactoring in gcc.mk

I like to avoid cut/paste in code, so I suggest the following small change in gcc.mk (from line 176):
AVR8_CC_FLAGS := -mmcu=$(MCU) -fshort-enums -fno-inline-small-functions -fpack-s
truct
ifeq ($(ARCH), AVR8)
BASE_CC_FLAGS += $(AVR8_CC_FLAGS)
else ifeq ($(ARCH), XMEGA)
BASE_CC_FLAGS += $(AVR8_CC_FLAGS)
else ifeq ($(ARCH), UC3)

Duplicate source names give error

I try to compile those files:

avrnacl_small/crypto_auth/hmac.c 
avrnacl_small/crypto_box/curve25519xsalsa20poly1305.c 
avrnacl_small/crypto_core/hsalsa20.c 
avrnacl_small/crypto_core/salsa20.c 
avrnacl_small/crypto_dh/curve25519.c 
avrnacl_small/crypto_hash/sha512.c 
avrnacl_small/crypto_hashblocks/sha512.c 
avrnacl_small/crypto_onetimeauth/poly1305.c 
avrnacl_small/crypto_scalarmult/curve25519.c 
avrnacl_small/crypto_secretbox/xsalsa20poly1305.c 
avrnacl_small/crypto_sign/ed25519.c 
avrnacl_small/crypto_sign/sc25519.c 
avrnacl_small/crypto_sign/precompute.c 
avrnacl_small/crypto_sign/ge25519.c 
avrnacl_small/crypto_stream/xsalsa20.c 
avrnacl_small/crypto_stream/salsa20.c 
avrnacl_small/crypto_verify/verify.c

But I get this error:

dmbs/DMBS/gcc.mk:95: *** Cannot build with OBJDIR parameter set - one or more object file name is not unique.  Stop.

If you look closer at the sources you will notice that sha512.c (and others) are available in two folders (but still different code inside). I think the folder structure is not kept in the output path and therefor this causes problems.

Using latest dmbs release-20160403 or newer (from git).

Add maximum sketch size limit

For coding bootloader (with no API table at the end) it would make sense to add an error if a specific program size is reached. Then you can set the bootloader size and if its bigger than the limit it outputs an error. Not sure if this is possible.

This would fix abcminiuser/lufa#72

Add output path

You can specify the path of the object files, but not the path of the other files (hex, bin, a, etc). It would be nice if you could safe them in a special directory called "out" or "bin".

Add avrdude-fuses and avrdude-all

Hi,
I am currently developing a device that requires to set special lock fuse bits after programming.
But I also need to upload an eeprom file. Locking the device before uploading the eeprom is a bad idea.

So it would be nice if you can:

  • Program the device (make avrdude)
  • Program eeprom (make avrude-ee)
  • Set fuses (make avrdude-fuses)
  • Use all of those in a row (make avrdude-all)

I already implemented a really quick fix for this:

# Programs in the target fuses using AVRDUDE
avrdude-fuses: $(MAKEFILE_LIST)
    @echo $(MSG_AVRDUDE_CMD) Programming device \"$(MCU)\" fuses using \"$(AVRDUDE_PROGRAMMER)\" on port \"$(AVRDUDE_PORT)\"
    avrdude $(BASE_AVRDUDE_FLAGS) $(AVRDUDE_FUSES) $(AVRDUDE_FLAGS)

avrdude-all: avrdude avrdude-ee avrdude-fuses

However it would be more nice to not expose the U:lfuse etc options tot he user. You'd need some magic if(fuse defined) then use param in avrdude.I have not done it because I dont know how to do it and it worked like this. If you can add this feature it would be super nice and helpful :)

File specific compiler options

Regarding #21 I generally want to enable LTO. However some files need to be compiled without LTO (you can use -fno-lto). However this is impossible with dmbs it seems. Do you know how to change/add compilation flags for single files? The only solution I can think of is to create multiple makefiles, which is a really bad idea, I already tried that.

Maybe a special target can be written for that file that can add additonal flags?

More details for my particular issue:
I got an inline asm function _micros Which I want to call with an inline asm call _micros. However the symbol name changes to this, when LTO is used. So I need to disabled LTO for this file. I did not found any other way. The number is also random:

00000000 l    d  .gnu.lto__micros.3cfd9897f8dbd587	00000000 .gnu.lto__micros.3cfd9897f8dbd587

Solution

gcc.mk (same for .c/.S files)

# Compiles an input C++ source file and generates a linkable object file for it
$(OBJDIR)/%.o: %.cpp $(MAKEFILE_LIST)
	@echo $(MSG_COMPILE_CMD) Compiling C++ file \"$(notdir $<)\"
	$(CROSS)-g++ -c $(BASE_CC_FLAGS) $(BASE_CPP_FLAGS) $(CC_FLAGS) $(CPP_FLAGS) $($(notdir $<)_FLAGS) -MMD -MP -MF $(@:%.o=%.d) $< -o $@

Makefile:

FastLED_compat.c_FLAGS = -fno-lto

Since every file must be unique #12 this should not be a problem if we do it like that.

Bump AVR c++ standard to 2014

Wouldnt it make sense to also upgrade the c++ standart to the latest version? c++11 was required for me multiple times already. Legacy programs can still set an older outdated standard via makefile.

arduino/Arduino#7090

Same for c standard.

Change compiler option

It would be nice if you could change the compiler to avr-g++ instead of avr-gcc for example. This is currently not working. I found an example online which might be similar to what we want to also use:

CXX = $(CROSS_COMPILE)-g++
CC = $(CROSS_COMPILE)-gcc
AS = $(CROSS_COMPILE)-as
AR = $(CROSS_COMPILE)-ar
NM = $(CROSS_COMPILE)-nm
LD = $(CROSS_COMPILE)-ld
OBJDUMP = $(CROSS_COMPILE)-objdump
OBJCOPY = $(CROSS_COMPILE)-objcopy
RANLIB = $(CROSS_COMPILE)-ranlib
STRIP = $(CROSS_COMPILE)-strip

This way we can always overwrite the CC or CXX compiler from avr-gcc to avr-g++. Also wouldnt it make sense to use avr-g++ for c++ files anyways? And if at least 1 c++ source was used, the LD should also be avr-g++?

Add include guard for core modules

If you include the core (or other) modules with other modules it should not be included again. Its a similar technique as in c header files. Its better to add the inclusion check into the core module than into your own module if you ask me. Correct me if I am wrong.

ifeq ($(findstring CORE, $(DMBS_BUILD_MODULES)),)
...
endif

I am willing to prepare a PR for this if you say this makes sense.

AVRDUDE: difference between chipIDs in AVR-GCC and AVRDUDE

In both GCC and AVRDUDE modules used one common variable - MCU. But this tools use different ids of the same chip. For example:
chip: ATMega128A
avr-gcc: atmega128a
avrdude: m128
Solving the problem could be adding to the module AVRDUDE it's own custom configuration file and passing them as command-line option -C config.file or adding AVRDUDE specific mandatory variable AVRDUDE_PART or AVRDUDE_MCU.
It is strange that this topic was not raised earlier. Or am I the only one who has come across this?

Add LTO option

An optional variable for this could be useful:

# LTO
CC_FLAGS  += -flto -fuse-linker-plugin
LD_FLAGS  += -flto -fuse-linker-plugin

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.