dev.ed.am
Arduino Makefile
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
bug_report_small.png
icon_project.png Arduino Makefile / Closed Bug report #12 mkdir -p .dep/./ fails on OSX Mavericks
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue basics
  • Type of issue
    Bug report
  • Targetted for
    0.6 release
  • Status
    Closed
  • Progress
  • Priority
    Not determined
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (0)
There are no items
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    RESOLVED
  • Reproducability
    Always
  • Severity
    Critical
Attachments (0)
There is nothing attached to this issue
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates
Description
Machine: Macbook Pro running OSX 10.9.1, (GNU)make version 3.81

In a sketch directory make fails at the %.o: %.ino rule. The line mkdir -p .dep/$(dir $<) resolves to mkdir -p .dep/./ which gets this error: "mkdir: .dep/./: No such file or directory"

I just removed the $(dir $<) part on the .ino/.pde rules.
Steps to reproduce this issue
cd into sketch directory which has this Makefile:
<source lang="php">
LIBRARIES := SPI SD
BOARD := uno
include ~/bin/arduino.mk
</source>
Then type make to produce failure.
Comments ()
#13
 edam (edam)
icon_reply.pngJan 09, 2014, in reply to comment #12
Carl_P wrote:
I can't get the dev version to work so I took your changes to the "mkdir"
lines and put them in version 5. I've built a few sketches and it seems to
work fine. Thanks. Shame we have to do it that way.


Excellent.

In the dev version this is the error I'm getting. I'll go back and see
what the problem is and report back.

sed: 1: "s/^menu\.cpu\.uno\.buil ...": bad flag in substitute command: 'I'


Ah, that is likely to be related to a fix I just committed for bug 11. I'll look at that. Thanks.

#12
 Carl_P (ccpetersen)
icon_reply.pngJan 08, 2014, in reply to comment #11
I can't get the dev version to work so I took your changes to the "mkdir" lines and put them in version 5. I've built a few sketches and it seems to work fine. Thanks. Shame we have to do it that way.

In the dev version this is the error I'm getting. I'll go back and see what the problem is and report back.

sed: 1: "s/^menu\.cpu\.uno\.buil ...": bad flag in substitute command: 'I'


BTW, I just received a DUE in the mail so I can really check out the dev version...

Thanks

edam wrote:
Carl_P, this is fixed in the latest development version of the makefile,
which you can get form here. If you'd mind reporting back to say if this
fixes the issue for you or not, I'd really appreciate it!


#11
 edam (edam)
Jan 08, 2014
Carl_P, this is fixed in the latest development version of the makefile, which you can get form here. If you'd mind reporting back to say if this fixes the issue for you or not, I'd really appreciate it!
#10
 edam (edam)
Jan 08, 2014
fixed in r96

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from Confirmed to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
#9
 edam (edam)
icon_reply.pngJan 08, 2014, in reply to comment #8
Carl_P wrote:
Yes, mkdir -p .dep/./ works fine in linux. No luck with sudo mkdir -p
.dep/./ here, still fails. I'm not sure why it would make a difference
since the "." directory is owned by the user.

The issue seems to be with the different mkdir. Anyone have a BSD box to
check with?


Both you and the other report of this issue are using OS X Maverick, too.

I'd test it in a VM, but it isn't going to change the fact that I'm going to have to fix it! So, I might as well not bother...

Incidentally, the fix you suggested (removing the $(dir $<) part) isn't an ideal solution. Those directories are there to make sure that two files with the same name in different subdirectories don't overwrite each other's dependencies. The only solution I can think of at the moment is to explicitly check for and strip off the ./ from the start of $(dir $<).

By the way thanks for all your work here!


No problems. Glad it's appreciated!

#8
 Carl_P (ccpetersen)
icon_reply.pngJan 08, 2014, in reply to comment #6
Yes, mkdir -p .dep/./ works fine in linux. No luck with sudo mkdir -p .dep/./ here, still fails. I'm not sure why it would make a difference since the "." directory is owned by the user.

The issue seems to be with the different mkdir. Anyone have a BSD box to check with?

By the way thanks for all your work here!

edam wrote:
Also, only to affects Macs. And may have just started happening after a
recent Xcode update.


#6
 edam (edam)
Jan 08, 2014
Also, only to affects Macs. And may have just started happening after a recent Xcode update.
#4
 edam (edam)
Jan 08, 2014
Another user reports this:

  mkdir -p .dep/./ fails in other directories, but mkdir -p .dep/ succeeds in the same directory
  
  however sudo mkdir -p .dep/./ worked


History