Re: [Gnu-arch-users] Make test failure on Cygwin

[John Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ron Parker wrote:
| On Tue, 06 Jul 2004 15:46:30 -0500, John Meinel <address@hidden>
wrote:
|
|>I'm very curious why the "sed" output is different from the
|>"unit-unidata" version. I know I have cygwin designed to use Unix line
|>endings internally. At least I believe so. (That's caused problems
|>trying to use cmd line cvs versus a Win32 gui cvs.)
|
|
|
| True but dos2unix is a Cygwinism and I was targeting something that
| would work regardless of OS. Two reasons here.  I use more operating
| systems than anyone should and I was hoping at some point in time to
| be able to at least have some of this merged back into the baseline.
|

Well, what about this "odd" workaround. "./unit-unidata | sed 's/ / /'"
You don't need dos2unix, and it forces both outputs to be processed by
the same command (sed). The sed should be pretty much a no-op, though
admittedly it isn't quite. Another possibility would be "| grep .".
Because my guess is that sed and grep will both open their input in the
same mode.

|
|
|>I don't know if this would be the problem, but what if tla is using the
|>wrong versions of tar/diff/patch etc?
|
|
| I don't think it would be using the wrong version because an explicit
| ../libexec path should be getting used to exec them.  However, as I
| previously mentioned I have not checked to see if it might be using a
| stale version that already exists from a previous install.

Where does it decide "../libexec"? I know the "make test" command has an
explicit path to the tla to run, does tla internally call
popen("../libexec/tar ...")?

Because I don't think that command works. ".." in that case is relative
to current working dir, not /opt/tla/bin, etc. I suppose you could do
dirname(argv[0]) + "%s../libexec/tar"

Though you need access to argv (and an equivalent to dirname) at that time.

I'm just curious how it is implemented. If you've put the changes in
your arch, I can check them out and see what I find.

|
|
|>Just the auto* errors. One thing I would say is probably we want to
|>distribute the "generic" Makefile.in. I was reading some of the help
|>files and unless you do "make distsomething" the Makefile.in may not be
|>a portable one. I would like to see the situation where ./configure runs
|>configure for all the packages, and then make only does the build.
|>Having make also run ./configure for the tar/patch/diffutils stuff
|>doesn't seem quite right.
|
|
| Take it up with the author of package framework. :^) Seriously, its
| been a few months since I dug into this and I _vaguely_ recall that
| Makefile.in must exist when configure is run weather or not the
| project is autotool based.
|
| Okay, I just rechecked this. Package framework calls the configure
| script for the autotools managed projects directly. It also relies on
| the functionality in the newer autotools that will essentially
| autoreconf everything if the generated files are out of date. (This
| happens when make is called.) Simply calling configure keeps the
| package framework from necessarily requiring an installation of a
| certain version of the autotools.
|

Well, what I'd like to see is that the Makefile.in files do exist in the
source repository. Makefile.am can be used to generate it, but that
should be done by you, it shouldn't be necessary to have autotools
installed to build the project.

Actually, from what I was seeing, the autotools screwed up more than
they helped (probably because I have a different version.) If I tried to
play around with any of the Makefile.* files it would try to re-generate
and then my build would fail. If I just did a fresh checkout, configure,
build, then things would work. And if I only changed hackerlab I could
type make again and it would work.

I don't remember what specific changes I tried before it would compile.
But in the end I found "don't touch anything but the source code" and it
will compile.

I did find that after running ./configure, I had to change the tar
Makefile, so that it would bind to libhackerlab.a, but trying to fix
that back before ./configure was not happy.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6zRzJdeBCYSNAAMRAjDmAJ4svfctOgdeOJidy2n9C5KEC+mYqQCePhzA
RvTEv1vfyYqBWa+BX2LAq64=
=z5HX
-----END PGP SIGNATURE-----