SD library does not link

[apmorton]

SD library does not link

[apmorton]

The issue is that while you have added utility to the include path, no c files from that subdirectory are being compiled.

Change the LCPP_FILES definition to this

LCPP_FILES := $(wildcard $(LIBRARYPATH)/*/*.cpp) $(wildcard $(LIBRARYPATH)/SD/utility/*.cpp)

A better solution would be to make LC_FILES recurse directories, but there isn't an easy way to do that without using $(shell find ...) to my knowledge, which isnt the most portable

[kasbah]

Ah yes, of course. Thanks!

LC_FILES := $(wildcard $(LIBRARYPATH)/*/*.c) $(wildcard $(LIBRARYPATH)/*/utility/*.c)
LCPP_FILES := $(wildcard $(LIBRARYPATH)/*/*.cpp) $(wildcard $(LIBRARYPATH)/*/utility/*.cpp)

A better solution would be to make LC_FILES recurse directories, but there isn't an easy way to do that without using $(shell find ...) to my knowledge, which isnt the most portable

Says the person that has the words "What is Win Dose?" in their makefile and put compiled binaries into their git repository ;)

[apmorton]

Touche. You just gave me a good laugh. It's been so long since I looked at
this project I forgot its targeted at nix specifically.
On Nov 21, 2014 6:24 AM, "Kaspar Emanuel" [email protected] wrote:

Ah yes, of course. Thanks!

LC_FILES := $(wildcard $(LIBRARYPATH)//.c) $(wildcard $(LIBRARYPATH)//utility/.c)
LCPP_FILES := $(wildcard $(LIBRARYPATH)//.cpp) $(wildcard $(LIBRARYPATH)//utility/.cpp)

A better solution would be to make LC_FILES recurse directories, but
there isn't an easy way to do that without using $(shell find ...) to my
knowledge, which isnt the most portable

Says the person that has the words "What is Win Dose?" in their makefile
and put compiled binaries into their git repository ;)

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

[kasbah]

You point is valid though. Detecting windows and removing the binaries is more easily fixable. Recursing might be harder.

[apmorton]

To be fair, I doubt a Windows user would hardly appreciate us removing all
their binaries from system32 instead of adding Windows support ;)
On Nov 21, 2014 6:32 AM, "Kaspar Emanuel" [email protected] wrote:

You point is valid though. Detecting windows and removing the binaries is
more easily fixable. Recursing might be harder.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

[kasbah]

:) Jokes aside it might be nice to point at the default Arduino location on Windows like on OSX.

I'll send a pull-request with these minor fixes anyway. The */utility/* wildcards fix the Audio library as well so I think it's worth doing.

Hopefully this means I can leave the Arduino IDE closed for another few months until I try the next Arduino compatible board.

[apmorton]

How many of the included arduino libraries use sub directories? My guess is
very few. A hacky solution is to just duplicate the wildcard there with
another subdirectory level.

//*.c basically.

Should cover any/all libraries. I can't imagine any use more than one
subdirectory.
On Nov 21, 2014 6:40 AM, "Kaspar Emanuel" [email protected] wrote:

:) Jokes aside it might be nice to point at the default Arduino location
on Windows like on OSX.

I'll send a pull-request with these minor fixes anyway. The /utility/
wildcards fix the Audio library as well so I think it's worth doing.

Hopefully this means I can leave the Arduino IDE closed for another few
months until I try the next Arduino compatible board.

—
Reply to this email directly or view it on GitHub
#7 (comment)
.

[kasbah]

Hmm yeah, */*/*.c is better. My thought was we don't want to compile the examples dir source files but those are normally two directories deep anyway.

I want to get rid of the binaries, they don't work on my (32-bit) Ubuntu either. It might actually be worth clearing the history of them because it really slows down git. You'd have to do that though (delete repo, create new one with the same name and then rm -rf .git && git init && git add . and commit and push that).