Ticket #411 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

make loops, rerunning configure ad infinitum

Reported by: vda Owned by: slyfox
Priority: major Milestone: 4.7.0-pre1
Component: mc-core Version: master
Keywords: committed-master Cc: pahan@…
Blocked By: #403, #413 Blocking:
Branch state: Votes for changeset:

Description (last modified by slyfox) (diff)

With current git tree, on my machine, I am able to run ./autogen.sh and then ./configure, but when I run make, I see that it runs

/bin/sh ./config.status --recheck

and when it finishes, it starts again:

...
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... x86_64-unknown-linux-gnu
...

changeset:d9a72ea8c9cc0b00cb8ded7178d61e56e4a2655d

Attachments

z.diff (1.4 KB) - added by vda 10 years ago.
Updated fix. I had to drop version.h updating from Makefiles, it does not work correctly. Previous fix was aborting because make still thinks the rule should be triggered.

Change History

comment:1 follow-up: ↓ 2 Changed 10 years ago by slyfox

to avoid this - run maint/version.sh before ./configure

comment:2 in reply to: ↑ 1 Changed 10 years ago by slyfox

to avoid this - run maint/version.sh before ./configure

It shoud not be very harmful if we will do it in autogen.sh

comment:3 follow-up: ↓ 4 Changed 10 years ago by vda

Makefile.in:

$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)

$(SHELL) ./config.status --recheck

After ./autogen.sh + ./configure, generated Makefile looks like this:

$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)

$(SHELL) ./config.status --recheck

CONFIG_STATUS_DEPENDENCIES is ./version.h, it does not exist, which causes reevaluation of the make rule.

version.h does not exist because maint/version.sh does this:

pushd ${src_top_dir} &>/dev/null
git_head=$(git rev-parse --verify HEAD 2>/dev/null)
[ -z "${git_head}" ] && exit

and "git rev-parse --verify HEAD" says "fatal: Not a git repository"
and we have ${git_head} empty.

I think we should not require that people have git and always build inside the git repository.

Changed 10 years ago by vda

Updated fix. I had to drop version.h updating from Makefiles, it does not work correctly. Previous fix was aborting because make still thinks the rule should be triggered.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5 Changed 10 years ago by slyfox

I think we should not require that people have git and always build inside the git repository.

We don't. I almost never run configure from git cloned directory. maint/version.sh has one exact purpose: to regenerate in-source version.h

If You dislike messing with git and do not want to use make dist (which generates needed stuff) - You can craft version.h Yourself the way You prefer.

Updated fix. I had to drop version.h updating from Makefiles, it does not work correctly.

What correctly means?

z.diff breaks all features it was designed for.

comment:5 in reply to: ↑ 4 Changed 10 years ago by slyfox

if test -x $srcdir/configure.mc; then

$srcdir/configure.mc "$@"

$srcdir/configure.mc "$@"
exit 1


fi
maint/version.sh


Ah, this piece explains Your changes in othed files.

If You place version.sh call before - all your problems shoud disappear. The rest of patch is not needed at all (and it breaks make dist users)

comment:6 Changed 10 years ago by slyfox

  • Blocked By 403 added

#403 touches this issue in some places:

  • non-bash fixes
  • version.h pregeneration

comment:7 Changed 10 years ago by vda

I think we should not require that people have git and always build inside the git repository.

We don't. I almost never run configure from git cloned directory. maint/version.sh has one exact purpose: to regenerate in-source version.h

I described exact steps I do in a source tree which is not a git repository (.git directory is removed from it): ./autogen.sh, then ./configure, then make. It does not work for me. Does it work for you? If yes, can you tell me what steps do you perform?

If You dislike messing with git and do not want to use make dist (which generates needed stuff) - You can craft version.h Yourself the way You prefer.

My point is not about liking or disliking git. It is about not having a dependency on git. "./configure; make" is better be working without any other steps, as many users are accustomized to building packages that way.

I am not "do not want to use make dist", I just had no idea "make dist" exists and how I am supposed to use it. Where is it documented?

Updated fix. I had to drop version.h updating from Makefiles, it does not work correctly.

What correctly means?

It means that with that patch, I can run ./autogen.sh (it still has to be run in git tree), then can run ./configure; make and build will be successful (even if I remove .git directory, or tar up and copy the tree to a machine without git, etc).

It looks like my problems are caused by the lack of small "HOWTO build mc from git snapshot". Maybe update in-tree doc/HACKING file ("Compiling from CVS" section) to help newbies like me? This would close this bug.

comment:8 Changed 10 years ago by Hubbitus

  • Cc pahan@… added

comment:9 Changed 10 years ago by slyfox

  • Blocked By 413 added

Bug also depends on #413

We'll add make-dist.sh script and some explanations about requirements and made decisions.

comment:10 Changed 10 years ago by angel_il

  • Milestone changed from 4.7 to 4.7.0-pre1

comment:11 follow-up: ↓ 12 Changed 10 years ago by iNode

And also, some system (like buildbot with basic settings) just do git-fetch repo master and so on, so ./maint/version.h can't create version.h (and loop infinitely in make).

I made workaround for buildbot, but there is many buildsystem in many distros that can be also embroiled for the same reasons.

I think we should break all build (./autogen.sh should do exit 1) or make it work independently of git repo.

comment:12 in reply to: ↑ 11 Changed 10 years ago by slyfox

  • Keywords review added

Replying to iNode:

And also, some system (like buildbot with basic settings) just do git-fetch repo master and so on, so ./maint/version.h can't create version.h (and loop infinitely in make).

I made workaround for buildbot, but there is many buildsystem in many distros that can be also embroiled for the same reasons.

I think we should break all build (./autogen.sh should do exit 1) or make it work independently of git repo.

I see. One more "advanced" client. version.sh now creates version.h in any circumstances. In worst case mc version will be seen as current sha1 on "unknown".

Tip: changeset:1c855116552705b73bf20496532721017f313d50
Start: changeset:b9ca21577a7333bb5e944c17a7ae80a4a189bf85

No need to explicitely build distribution then. It is usually done as:

./autogen.sh
./configure
make dist

Documentation/tarball maintainership scripts will be updated slighlty later.

comment:13 Changed 10 years ago by iNode

  • Keywords vote-iNode added

Yeah, it should work. I modeled process of buildbot work, all seems to be correct.

$ src/mc -V | grep GNU
GNU Midnight Commander 1c855116552705b73bf20496532721017f313d50

My vote here.

comment:14 Changed 10 years ago by slavazanko

  • Status changed from new to assigned
  • Keywords vote-slavazanko approved added; review removed
  • Owner set to slyfox

comment:15 Changed 10 years ago by slyfox

  • Status changed from assigned to testing
  • Keywords committed-master added; vote-iNode vote-slavazanko approved removed
  • Resolution set to fixed
  • Description modified (diff)

comment:16 Changed 10 years ago by slavazanko

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.