search

SirWumpus / post4

Post4 is an indirect threaded Forth dialect written in C.
BSD 2-Clause "Simplified" License
4 stars 1 forks source link

Remove `configure` from the repo #11

Closed ruv closed 1 month ago

ruv commented 2 months ago

When I update repo by git pull --ff-only, I get error from git:

error: Your local changes to the following files would be overwritten by merge:
        configure

Probably, the file configure should be added into .gitignore and removed from the repo.

SirWumpus commented 2 months ago

The problem is if there was an out of date configure in the repo, which means the user will generate their own if they have autoconf installed, so a subsequent git pull will conflict if a newer configure is supplied.

The workaround is to git checkout -f first to discard changes, then git pull. It might be possible to do this in one go with git pull -f.

A pre-generated configure should be part of the repo for those who need it, typically tarball downloads.

However, I'll see if I can improve the process.

ruv commented 2 months ago

The workaround is to git checkout -f first to discard changes, then git pull. It might be possible to do this in one go with git pull -f.

Then the timestamp of configure will be newer than the timestamp of some file it depends on. And make build will regenerate it again (without a need). And the version in the working directory will again differ from the version in the repo.

Update and correction: if configure is newer, it should not be regenerated; but in my tests it is regenerated, probably because the timestamp of some file it depends on is made newer by Git.

What if you rename configure to configure.orig in the repo, and use it to create configure if autoconf is absent?

Something like:

configure : configure.orig configure.ac aclocal.m4
    { command -v ${AUTOCONF} >/dev/null && ${AUTOCONF} -f ; } || ln -f $< $@

Or, better:

configure : configure.orig configure.ac aclocal.m4
    cmd="${AUTOCONF} -f"; { command -v ${AUTOCONF} >/dev/null || cmd="ln -f $< $@" ; } ; $$cmd
ruv commented 2 months ago

See also a StackOverflow question: Should a "configure" script be distributed if configure.ac is available?

The idea is that the version control system should not be used as a distribution system.

According to this approach, the file configure can be automatically included into the tarbal, or downloaded from the Release section.

I used this approach to download a binary that is required for building (example).

SirWumpus commented 2 months ago

I have mix feelings on this. Personally I prefer not to supply generated files ("just the facts source please"), BUT I have had other people with my other repositories complain when it is not supplied. So currently I supply it. Frankly I'd love to move away from autoconf and ./configure, but some projects do benefit from it (if only BSD and Linux had the same file system layout and naming conventions). (And NO I do not want to learn cmake.)

Now, Post4 is originally suppose to be ISO C compatible (for the most part), so maybe I can assume more about that environment and I'm making the building less complex; though now I have Java support in the mix. When I finally caved into autoconf about 20 years ago, I just accepted that some facts about a system can't always be assumed across all the platforms I've worked on and just assumed that many will need configure and it is a habit I carry into each project.

If I could prune back to a basic config.h and Makefile that installers twiddle (when defaults don't work), that would be nice. Another Post4 user, @wboeke, has expressed his dislike of configure too and would welcome this direction.

Right now this is a meta distribution and build problem. I'm going to park this while there are more immediate issues with Post4 standards conformance to address.

ruv commented 2 months ago

Right now this is a meta distribution and build problem. I'm going to park this while there are more immediate issues with Post4 standards conformance to address.

Agreed :)

SirWumpus commented 2 months ago

v0.10.0 I have modified the ./configure generate script to avoid unnecessary regeneration, however I won't remove it for now. Still need to consider that choice more.

Going to leave this open for a while just to remind me review it ever so often.

ruv commented 2 months ago

Now it works: the configure file is not changed at all.

SirWumpus commented 1 month ago

Leaving as it is now.