Follow-up Comment #8, bug #62595 (project make): > Of course you can also use the re-exec feature of make to write a rule to generate the include file then you have the full power of a recipe. I like the idea, especially because of the re-exec feature. However, my goal was to avoid having to make this external to make. Also given that the rule for recipe is not likely to change from project to project, I would like to suggest an alternative (and possibly simpler) abstraction:
What if we have a special target rule, which has dependencies on any number of ".env" files: .ENVFILES: .env production.env This will have the job of parsing the env files and including them into make. > I'm also not sure I agree that the right behaviour is to always export every variable in the file. But these are details:... I suggested the _always export_ option because that's usually the way I've seen .env files being used. For example, when working with docker-compose yaml files, docker-compose reads a .env file and any other included yaml files can also see the variables. _See the syntax rules for .env <https://docs.docker.com/compose/env-file/#syntax-rules>_ The same is true for most people who use .env files with shell scripts. Some will do something like this to automatically export and load the variables into the current process: set -a; source .env; set +a Pipenv <https://pipenv.pypa.io/en/latest/> which is used to manage a python project dependencies will also usually load the .env file into the current process, and every program that is started sees the environments. In any case, I don't think lack of automatic export is a deal breaker. If the current plan is to create an external program, or to use the special target, then decision to export or not can be made later rather than now. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?62595> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/