RFC: use makefile switch

[dahankzter]

I am not sure if this has been discussed somewhere but if so I apologize.

My suggestion is just a switch "-make" or "-use-make" to tell looper to use a makefile if one is available possibly recursively for each directory.

If you agree that it is sound or have another suggestion I am willing to give it a shot at implementing it.

[nathany]

@dahankzter Sounds like a good suggestion. I've added it to the roadmap.

I don't currently have a good way to pass switches around, and I'm still trying to figure out better ways to generalize the system (build/test/assets) while also providing interactions for things like memory profiling and benchmarks.

Lets leave this on the back burner until I do some restructuring. Thanks.

[nathany]

@dahankzter Do you have any particular requirements for what this flag would do? Just run make test?

[dahankzter]

That would work for my case but if you have something more generic in mind like -exec "my_build.sh" or similar that works fine too.

Both options would probably be nice. -make=test and -exec=script.sh.

If you want to hide the make arguments then "make test" is probably a good target.

[nathany]

Recently support was added to detect Godep and automatically use the right command there. It's an interesting approach that is nice when it works, I'm not sure how far I can take it.

But detecting "Makefile" and running "make test" instead is a possibility.

[dahankzter]

Perhaps just allowing arbitrary exec? It would make for a simple way to run whatever on change and not limit it to building Go projects?

The use case in mind right now is that on a mixed Mac and Linux team the linux users has a really easy way to use inotify-tools to do this but on Mac it seems to be a hassle. Having a tool like looper would be really neat and would make it easy to use on different envs. A general purpose fallback "exec" method would allow us to use looper for most everything and once a particular use case falls out as very common we could talk to you and perhaps extend its API with a new switch.

These things could (off the top of my head) be perhaps make it docker aware or something else completely unknown. Not suggesting it, it was just an example.

[nathany]

Some combination of arbitrary exec and built in features could make for a good combo. I'll give it some more thought.