OpenBSD 2.7

[Pavel Roskin]

Hello!

I've just installed OpenBSD 2.7.

Good news: the testsuite passes with one test ignored (due to lack of
/lib/cpp) and 160 tests passed! The only additional GNU packages were
m4-1.4, sed-2.05 and make-3.78.1

Bad news: the native make doesn't work - it cannot create "autoconf" and
other scripts because they have both explicit and suffix rules:

$(bin_SCRIPTS): configure.in   
   

.sh:   
   
rm -f $@ $@.tmp
   
$(editsh) $< >$@.tmp   
   
chmod +x $@.tmp
   
mv $@.tmp $@   
   

I did use "make dist" to create the tarball - it doesn't help.

Regards,
Pavel Roskin

Re: OpenBSD 2.7

[Lars Hecking]

> I've just installed OpenBSD 2.7.
> 
> Good news: the testsuite passes with one test ignored (due to lack of
> /lib/cpp) and 160 tests passed! The only additional GNU packages were
> m4-1.4, sed-2.05 and make-3.78.1
 
 Have you tried the native m4, too? See

 http://sources.redhat.com/ml/autoconf/2000-03/msg00213.html

 and follow-ups.

> Bad news: the native make doesn't work - it cannot create "autoconf" and
> other scripts because they have both explicit and suffix rules:
[...]

 BSD makes in their current form suck outright. Many of them don't even
 pass variables down to sub-makes. This is the main raison d'etre for
 gmake on my OBSD and NBSD systems ...

 I expect this to improve substantially with OBSD 2.8, Marc Espie has put
 a lot of good work into make (and I hope that the other BSDs follow suit).

Re: OpenBSD 2.7

[Akim Demaille]

> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes:

Lars>  Have you tried the native m4, too? See

Lars>  http://sources.redhat.com/ml/autoconf/2000-03/msg00213.html

It won't work: we depend on the tracing options, and Marc has not
imported this in his M4.

Re: OpenBSD 2.7

[Pavel Roskin]

Hello, Lars!

> > Bad news: the native make doesn't work - it cannot create "autoconf" and
> > other scripts because they have both explicit and suffix rules:
> [...]
> 
>  BSD makes in their current form suck outright. Many of them don't even
>  pass variables down to sub-makes. This is the main raison d'etre for
>  gmake on my OBSD and NBSD systems ...

Ok, they may suck, but Automake manages somehow to be compatible with
them. It's the code from Autoconf's Makefile.am that breaks BSD make.

Now we have this in the top-level Makefile.am:

# Follow the version number changes.
$(bin_SCRIPTS): configure.in

When BSD make scans for rules to make autoconf it picks the explicit rule
first, but it's empty. I believe that there is no way to use the suffix
rule in BSD make if an explicit rule is present.

This can be very frustrating for BSD users because make doesn't repost any
error, but "autoconf" and other scripts are not created.

Possible soultions:

1) Remove the explicit rule. Whenever configure.in changes "make clean"
will need to be run. It can only be a problem for Autoconf developers who
don't clean the working directory on updates (i.e. not for me). And it's a
very minor problem after all.

2) Use AM_MAINTANER_MODE. Seems to be an overkill.

3) Write explicit rules for every script and include configure.in in the
dependencies.

4) Include the dependency on configure.in in the suffix rule. I'm afraid
it's impossible.

Better ideas?

Regards,
Pavel Roskin

Re: OpenBSD 2.7

[Akim Demaille]

| Now we have this in the top-level Makefile.am:
| 
| # Follow the version number changes.
| $(bin_SCRIPTS): configure.in
| 
| When BSD make scans for rules to make autoconf it picks the explicit rule
| first, but it's empty. I believe that there is no way to use the suffix
| rule in BSD make if an explicit rule is present.

I just observed the same failure from SunOS' stock make.

Re: OpenBSD 2.7

[Pavel Roskin]

Hello, Akim!

> | Now we have this in the top-level Makefile.am:
> | 
> | # Follow the version number changes.
> | $(bin_SCRIPTS): configure.in
> | 
> | When BSD make scans for rules to make autoconf it picks the explicit rule
> | first, but it's empty. I believe that there is no way to use the suffix
> | rule in BSD make if an explicit rule is present.
> 
> I just observed the same failure from SunOS' stock make.

So let's remove the explicit rule. It's only helpful to maintainers, but
they are supposed to clean up the working directory from time to time.

Another solution would be AM_MAINTAINER_MODE in configure.in and @MAINT@
before the explicit rule, but I believe it's an overkill.

Regards,
Pavel Roskin

Re: OpenBSD 2.7

[Akim Demaille]

> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:

Pavel> So let's remove the explicit rule. It's only helpful to
Pavel> maintainers, but they are supposed to clean up the working
Pavel> directory from time to time.

Grmph.  I wish Automake could expand this by itself.

Pavel, I believe you understood quite well the make bug which is
triggered by our Makefile.  Could you specify it in the documentation?

Pavel> Another solution would be AM_MAINTAINER_MODE in configure.in
Pavel> and @MAINT@ before the explicit rule, but I believe it's an
Pavel> overkill.

Over my dead body :)  I'm strongly opposed to the maintainer mode.

Re: OpenBSD 2.7

[Jim Meyering]

Akim Demaille <[EMAIL PROTECTED]> wrote:

| > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
|
| Pavel> So let's remove the explicit rule. It's only helpful to
| Pavel> maintainers, but they are supposed to clean up the working
| Pavel> directory from time to time.
|
| Grmph.  I wish Automake could expand this by itself.
|
| Pavel, I believe you understood quite well the make bug which is
| triggered by our Makefile.  Could you specify it in the documentation?
|
| Pavel> Another solution would be AM_MAINTAINER_MODE in configure.in
| Pavel> and @MAINT@ before the explicit rule, but I believe it's an
| Pavel> overkill.
|
| Over my dead body :)  I'm strongly opposed to the maintainer mode.

Likewise :-)  I really regret introducing that.
I should have reacted more quickly to François' objection to it.
If only...

Re: OpenBSD 2.7

[Pavel Roskin]

Hello, Akim!

> Pavel> So let's remove the explicit rule. It's only helpful to
> Pavel> maintainers, but they are supposed to clean up the working
> Pavel> directory from time to time.
>
> Grmph.  I wish Automake could expand this by itself.

Actually, it should. The scripts are created by config.status, hence they
depend on config.status. This rule would be sufficient, since
config.status is already rebuilt whenever configure.in is touched.

In general, Automake should add a dependency on config.status for every
file created by it.

It's easy to blame Automake, however, it's unclear whether Automake will
be able to generate something better than what we have now. We have a
suffix rule and we know that it will have no effect for BSD make when an
explicit rule is present.

This means that Automake will have to generate explicit rules for every
script.

In fact, we can "generate" them right now by hand.

Regards,
Pavel Roskin

Re: OpenBSD 2.7

[Lars Hecking]

 Argh!

 Please stop CC'ing me in this thread! I am subscribed to this list!!

Pavel Roskin writes:
> Hello, Akim!
> 
> > Pavel> So let's remove the explicit rule. It's only helpful to
> > Pavel> maintainers, but they are supposed to clean up the working
> > Pavel> directory from time to time.
> >
> > Grmph.  I wish Automake could expand this by itself.

Re: OpenBSD 2.7

[Earnie Boyd]

--- Lars Hecking <[EMAIL PROTECTED]> wrote:
> 
>  Argh!
> 
>  Please stop CC'ing me in this thread! I am subscribed to this list!!
> 

Speaking only for myself and not for anyone else, I'll have to say that you'll
have to fix that problem yourself with a Reply-To: field back to this list. 
Lists such as this one, warrants replies to all addressees as it is an open
list and often the poster will not be a list member.  I don't have time to
filter out any particular one person from the address fields.

Cheers,

=
Earnie Boyd
mailto:[EMAIL PROTECTED]

---  ---
--- Cygwin: POSIX on Windows  ---
---   Minimalist GNU for Windows    ---

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: OpenBSD 2.7

[Peter Eisentraut]

Pavel Roskin writes:

> In general, Automake should add a dependency on config.status for every
> file created by it.

(The scripts are not created by config.status, but anyway...)

All these dependencies with config.status, configure, Makefile.in, etc.
are really cute but when you think about it in order for them to be really
useful every target file under makefile control needs to depend on the
makefile used to build it.  For example, the rule might have changed, or
the tool to build it is now another.  Otherwise, why are you recreating
the makefiles at all?

Of course doing that is not a feasible option, so before long you're going
to have to realize that complete dependencies are not practical.  It
sounds very absurd anyway if you make changes in the build system and
expect the very same build system to recover from that.

I.e., you might want to consider removing the explicit rule.  How often
does one change the version number?

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: OpenBSD 2.7

[Lars J. Aas]

On Thu, Dec 07, 2000 at 08:13:22AM -0800, Earnie Boyd wrote:
: --- Lars Hecking <[EMAIL PROTECTED]> wrote:
: >  Please stop CC'ing me in this thread!
: 
: Speaking only for myself and not for anyone else, I'll have to say that you'll
: have to fix that problem yourself with a Reply-To: field back to this list. 

Good point and thanks for the tip.  This has bothered me too from time to time -
now I might remember how to avoid it...

  Lars J
-- 
Innovation is one percent inspiration and ninetynine percent perspiration,
and in my case; twice that...  -- Norville Barnes, `The Hudsucker Proxy'

Re: OpenBSD 2.7

[Akim Demaille]

> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:

Lars> Good point and thanks for the tip.  This has bothered me too
Lars> from time to time - now I might remember how to avoid it...

This is not nice, and I find this even bad: what about the other
people who are in CC: you are deciding they have to get lost.

Why don't you use (just like Lars did) to

Mail-Copies-To: never

Re: OpenBSD 2.7

[Pavel Roskin]

Hello, Peter!

> > In general, Automake should add a dependency on config.status for every
> > file created by it.
>
> (The scripts are not created by config.status, but anyway...)

You are right. Perhaps I didn't sleep enough this night :-/

> Of course doing that is not a feasible option, so before long you're going
> to have to realize that complete dependencies are not practical.  It
> sounds very absurd anyway if you make changes in the build system and
> expect the very same build system to recover from that.

Indeed, if I have a project in C and the version is hardcoded in one of
the object files, the executable will not be rebuilt when I touch
configure.in.

Doing otherwise would mean either rebuilding the whole project or
determining by some magic which object files have the version hardcoded.

> I.e., you might want to consider removing the explicit rule.  How often
> does one change the version number?

I already suggested it, but with your arguments I feel much better about
doing so.

Regards,
Pavel Roskin

Re: OpenBSD 2.7

[Akim Demaille]

> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:

>> I.e., you might want to consider removing the explicit rule.  How
>> often does one change the version number?

Pavel> I already suggested it, but with your arguments I feel much
Pavel> better about doing so.

Sorry, but I do not want to break valid rules due to stupid systems.
If you want to expand by hand, fine with me.  If you want to remove
valid dependencies, I won't agree.

Re: OpenBSD 2.7

[Peter Eisentraut]

Pavel Roskin writes:

> 4) Include the dependency on configure.in in the suffix rule. I'm afraid
> it's impossible.

This actually works in BSD make, but maybe not everywhere else.

(The dependency should be on Makefile anyway.)

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Warning on OpenBSD 2.7

[Pavel Roskin]

Hello!

First of all, I apologize for not having tested Autoconf on OpenBSD 2.7
immediately before the release. I had tested it few days before that, and
it worked. I didn't check the latest CPP changes. I accept full
responsibility for letting this problem go into 2.50 :-(

The "configure" script created by Autoconf-2.50 from the following file:

AC_INIT
AC_PROG_CPP
AC_OUTPUT

emits a warning when it's run by the native shell on OpenBSD 2.7:

./configure[1668]: break: can only break 1 level(s)

Indeed, "break 2" is inside one loop only. The comment in AC_PROG_CPP
says: "break 2 since there is a loop in there". But it's not true -
_AC_PROG_PREPROC_WORKS_IFELSE expands $1 after the loop.

Unfortunately, the warning in /bin/sh on OpenBSD causes several tests to
fail. I don't think there may be any real problems, since AC_PROG_CPP is
highly unlikely to be called in a loop.

Here's the fix. ChangeLog:

* aclang.m4 (AC_PROG_CPP): Use `break' instead of `break 2' since
_AC_PROG_PREPROC_WORKS_IFELSE expands arguments outside the loop.
(AC_PROG_CXXCPP): Likewise.


--- aclang.m4
+++ aclang.m4
@@ -881,8 +881,7 @@
 # Double quotes because CPP needs to be expanded
 for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
 do
-  # break 2 since there is a loop in there.
-  _AC_PROG_PREPROC_WORKS_IFELSE([break 2])
+  _AC_PROG_PREPROC_WORKS_IFELSE([break])
 done
 ac_cv_prog_CPP=$CPP
   ])dnl
@@ -1089,8 +1088,7 @@
 # Double quotes because CXXCPP needs to be expanded
 for CXXCPP in "$CXX -E" "/lib/cpp"
 do
-  # break 2 since there is a loop in there.
-  _AC_PROG_PREPROC_WORKS_IFELSE([break 2])
+  _AC_PROG_PREPROC_WORKS_IFELSE([break])
 done
 ac_cv_prog_CXXCPP=$CXXCPP
   ])dnl


Regards,
Pavel Roskin

Re: Warning on OpenBSD 2.7

[Akim Demaille]

>>>>> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:

Pavel> First of all, I apologize for not having tested Autoconf on
Pavel> OpenBSD 2.7 immediately before the release. I had tested it few
Pavel> days before that, and it worked. I didn't check the latest CPP
Pavel> changes. I accept full responsibility for letting this problem
Pavel> go into 2.50 :-(

You shall be beaten to death :)

Sure, please, apply.