I like the idea of makepp caching engine very much. However I see some annoyances which I hope can be improved.
1. The default action once caching is turned on is to cache *everything*. The manual then says that you can disable the caching for specific tasks. However in my case I want it only cache *.o files. There seems to be no way though that you can specify this. You would have to enable it and then disable all tasks in other makefiles… very error prone and timeconsuming.
2. Auto-cleanup of the caching would be VERY nice. I dislike the idea that you need to maintain it manually and do cron-jobs to clean it up. ccache is another caching engine and it works very simply by letting you specify a maximum size e.g. 1 gb. Once it's near that limit it will clean it up by 20%.
Isn't there an option to improve these things?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. Both http://makepp.sourceforge.net/1.50/makepp_rules.html#build_cache__path_to_build_cache and makepp_build_cache.html#how_to_tell_makepp_to_use_the_build_cache tell you how you can set a build cache just for one rule. Of course for your case this means replicating the builtin "%.o: %.cpp" rule in your makefile, but that's no big deal.
I have tried to make the 1st page above a little clearer. If you are not happy with the extensive documentation that comes with makepp, it would also be a great help to submit patches with clearer formulations for the doc!
2. The external tool allows many different strategies. The things it can do are quite expensive and it would be counter productive to have every call to makepp repeat this analysis. Also there are strategies that can only be performed by root.
I can see the use case for cleaning according to overall size, but that is more expensive to do, because you must traverse the cache stat'ing every file once to find it's current size. Then again to do the cleanup according to whatever criteria. With grouped cache there is also the question what size means: The apparent size (which would be the one if everything were on one disk, but which none of the grouped disks will usually attain) or the maximum size of one of the disks in the group (which is a more realistic measure).
All feasible but not a high priority. You could run the cron every hour, and as an approximation start the clean only if "du -s ." says the cache is too full.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea of makepp caching engine very much. However I see some annoyances which I hope can be improved.
1. The default action once caching is turned on is to cache *everything*. The manual then says that you can disable the caching for specific tasks. However in my case I want it only cache *.o files. There seems to be no way though that you can specify this. You would have to enable it and then disable all tasks in other makefiles… very error prone and timeconsuming.
2. Auto-cleanup of the caching would be VERY nice. I dislike the idea that you need to maintain it manually and do cron-jobs to clean it up. ccache is another caching engine and it works very simply by letting you specify a maximum size e.g. 1 gb. Once it's near that limit it will clean it up by 20%.
Isn't there an option to improve these things?
1. Both http://makepp.sourceforge.net/1.50/makepp_rules.html#build_cache__path_to_build_cache and makepp_build_cache.html#how_to_tell_makepp_to_use_the_build_cache tell you how you can set a build cache just for one rule. Of course for your case this means replicating the builtin "%.o: %.cpp" rule in your makefile, but that's no big deal.
I have tried to make the 1st page above a little clearer. If you are not happy with the extensive documentation that comes with makepp, it would also be a great help to submit patches with clearer formulations for the doc!
2. The external tool allows many different strategies. The things it can do are quite expensive and it would be counter productive to have every call to makepp repeat this analysis. Also there are strategies that can only be performed by root.
I can see the use case for cleaning according to overall size, but that is more expensive to do, because you must traverse the cache stat'ing every file once to find it's current size. Then again to do the cleanup according to whatever criteria. With grouped cache there is also the question what size means: The apparent size (which would be the one if everything were on one disk, but which none of the grouped disks will usually attain) or the maximum size of one of the disks in the group (which is a more realistic measure).
All feasible but not a high priority. You could run the cron every hour, and as an approximation start the clean only if "du -s ." says the cache is too full.