OpenSSL Communities
Tue 26 Aug 2025 11:53AM

Dealing with autogenerated files

DB Dmitry Belyavsky Public Seen by 19

Dear colleagues,
I don't like the situation with autogenerated files.

Paul's efforts on dealing with parameters are much appreciated, but the result comes with a cost.

If we modify the autogenerated file by accident, we lose its content on `make clean` invocation (see https://github.com/openssl/openssl/discussions/28269). If we navigate to the autogenerated file by tag and don't know that it was expanded from the template,

The parameters are now not greppable until we make a real configure and generate the files. That is counter-intuitive and problematic for people who try to find smth by the constant corresponding to the param name (now we at least should have these constants in the generated code).

AFAIK, curl developers keep both the template file and generated file in the repo. Following this example and detecting the mismatch would save us both from losing our work by accident and problems with grep. However it will require implementing some mechanism to detect mismatch between the generated file and the template.

WDYT?

RL

Richard Levitte Thu 28 Aug 2025 10:18AM 

Maybe this answers your concern, but kinda differently:

clean:
	...
	$(RM) $(GENERATED_MANDATORY) $(GENERATED)
DB

Dmitry Belyavsky Thu 28 Aug 2025 11:18AM

@Richard Levitte sorry, I don't get.
My goal is
- not lose the changes introduced into generated files by accident
- make sure that a particular param can be found and it's possible to see how it used without build

The 1st is mine problem, the 2nd problem is the problem of a 3rd-party developer who tries to understand how the particular parameter is processed (and yes, I'm talking about real colleagues and real issue they meet)

RL

Richard Levitte Thu 28 Aug 2025 1:43PM

@Dmitry Belyavsky, what I meant was that before worrying about timestamps being removed by 'make clean', we need to worry about the generated files themselves, which 'make clean' already removes.

DB

Dmitry Belyavsky Thu 28 Aug 2025 2:12PM

That's my original point - I think we should stop doing this

RL

Richard Levitte Mon 1 Sep 2025 11:04AM

Regarding `make clean`, a different approach than what has already be proposed is to look at precedents. Our `clean` target is pretty much along the lines of the GNU spec (see https://www.gnu.org/prep/standards/standards.html#Standard-Targets), so perhaps their approach with the `mostlyclean` target could be a way forward?