search

sociomantic-tsunami / makd

A Make library/framework to build D projects
Boost Software License 1.0
9 stars 20 forks source link

mkpkg: Add ability to map entire directories #69

Closed gkotian closed 7 years ago

gkotian commented 7 years ago

Currently, 'FUN.mapfiles()' returns an empty list on attempting to simply map directories (i.e. with no file names passed into the function). Fix this so that the function returns a simple mapping from the given source directory to the given destination directory if no file names are passed.

I'm targeting v1.9.x as I consider this a bugfix rather than a new feature. There is also no release notes update for the same reason.

leandro-lucarella-sociomantic commented 7 years ago

Mmm, if this is a bug fix I wonder if mapbins should get it too...

gkotian commented 7 years ago

Mmm, if this is a bug fix I wonder if mapbins should get it too...

Not worth the effort imo. mapbins() got deprecated not too long after it came into existence, so doesn't really have that many users I guess.

leandro-lucarella-sociomantic commented 7 years ago

Submitted #78 as an alternative solution.

Shall we close this one then?

gkotian commented 7 years ago

Submitted #78 as an alternative solution.

Shall we close this one then?

I don't know, it's your call really. According to me, this is a superior manner of addressing the problem. To borrow a term from dconf 2017, this solution is the "pit of success" model, wherein even if a programmer makes a mistake, things still just work. #78 otoh disallows the programmer from making the mistake. I'm ok with either approach.

llucax commented 7 years ago

I don't know, it's your call really. According to me, this is a superior manner of addressing the problem. To borrow a term from dconf 2017, this solution is the "pit of success" model, wherein even if a programmer makes a mistake, things still just work. #78 otoh disallows the programmer from making the mistake. I'm ok with either approach.

The problem here is making this a "pit of success" could also make the code for other people overly verbose, as I explain in #80. In any case, I definitely think #80 is better than this approach, so I will close this one as wontfix and we'll see where #80 leads us.