Hi Max, first of all, thanks for doing this enhancement. That'll really help in the future when downstream vendors merge in additional certificates (or remove some) like we do with SapMachine. Currently we have to resolve manually everytime cacerts is modified.
As for the dependencies: if you want to handle removals of certificates you might want to consider having a target that counts files in make/data/cacerts and stores the count in an intermediate file. You can do the counting every time (e.g. phony target) but only update the count file if the number has changed. And the actual cacerts target would need to depend on the count file as well. However, I guess it would also be ok to just depend on all the files in make/data/cacerts. Looking forward to see your update with Erik's suggestions worked in. Some copyright years need to be updated as well. Thanks & Best regards Christoph > -----Original Message----- > From: build-dev <build-dev-boun...@openjdk.java.net> On Behalf Of > Weijun Wang > Sent: Donnerstag, 30. Mai 2019 17:32 > To: Erik Joelsson <erik.joels...@oracle.com> > Cc: security-dev@openjdk.java.net; build-dev <build- > d...@openjdk.java.net> > Subject: Re: RFR 8193255: Root Certificates should be stored in text format > and assembled at build time > > > > > On May 30, 2019, at 10:01 PM, Erik Joelsson <erik.joels...@oracle.com> > wrote: > > > > In my experience, using directories for dependencies in make does not > work well. Since all the files in make/data/cacerts are in a flat structure, I > would recommend expressing the prerequisites as: > > > > $(wildcard $(GENDATA_CACERTS_SRC)/*) > > > > This will not cover the case where a file is removed, but that case is > > rarely > handled well in make based build systems. > > But in my experiment, using the directory name does detect the file removal. > > Or, can I list *both* the files and the directory to get maximum awareness? > > --Max
