Some genius had the idea of adding a new file (print-slow.c) to the
repository few hours before the x.9.2 release, without at least trying
to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
under Windows (even if it used to compile the night before the release).
We already checked in a patch, are there plans for a x.9.3 release? If
yes, could people stop to do breaking commits before it's done?
Loris and Gianluca
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Loris Degioanni wrote:
Some genius had the idea of adding a new file (print-slow.c) to the
repository few hours before the x.9.2 release, without at least trying
to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
under Windows (even if it used to compile the night before the release).

There needs to be a developer's document of some sort that says "if you
add a source file to tcpdump, you need to add it to:

Makefile.in;

FILES;

INSTALL (well, that's not a *requirement*, but it's a good idea);

win32/prj/GNUmakefile;

win32/prj/WinDump.dsp;

and give examples of what's added to all those files.

Ethereal avoids problems such as these by not doing Win32 projects -
builds are done with command-line "nmake" - and having both the nmake
files and the Makefile.am files include Makefile.common files, so that
there's only *one* list of files.

It also catches at least some other problems by using Buildbot:

so at least some build problems get caught (if tcpdump were to do the
same, the builds should be done from tarballs generated by "make tar",
so that it catches files not added to FILES).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Tue, Jul 12, 2005 at 11:10:38PM -0700, Loris Degioanni wrote:
| Some genius had the idea of adding a new file (print-slow.c) to the
| repository few hours before the x.9.2 release, without at least trying
| to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
| under Windows (even if it used to compile the night before the release).

that was me - guilty;

| We already checked in a patch, are there plans for a x.9.3 release? If
| yes, could people stop to do breaking commits before it's done?

you could help me avoiding those things by writing up a document that
describes what files you need on windows to be touched / added;
i only test on freebsd and linux;

/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Message
From: "Hannes Gredler" <hannes (AT) juniper (DOT) net>
To: <tcpdump-workers (AT) lists (DOT) tcpdump.org>
Cc: <tcpdump-workers (AT) tcpdump (DOT) org>
Sent: Wednesday, July 13, 2005 4:35 AM
Subject: Re: [tcpdump-workers] print-slow.c

Tue, Jul 12, 2005 at 11:10:38PM -0700, Loris Degioanni wrote:
| Some genius had the idea of adding a new file (print-slow.c) to the
| repository few hours before the x.9.2 release, without at least trying
| to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
| under Windows (even if it used to compile the night before the release).

that was me - guilty;

| We already checked in a patch, are there plans for a x.9.3 release? If
| yes, could people stop to do breaking commits before it's done?

you could help me avoiding those things by writing up a document that
describes what files you need on windows to be touched / added;
i only test on freebsd and linux;

This is surely a good idea, and we'll work on it as soon as possible. As we
have always done, we continue to offer our time to include patches for
Windows, and make sure that the releases compile and work on this platform,
too. However, our feeling is that the problem here is not "oops, I forgot to
fix/commit <somefile>, and now it doesn't build on platform XYZ". This can
happen (and it happens) to everyone. The *real* problem here is the release
process: our opinion is that, when a release should be done, there should be
an announce to the people having write access to the CVS, and *from that
moment on* and for the next 24/48 hours (at least) only the person
responsible for the release is allowed to commit anything on the release
branch, unless some big problem is found during the release testing.
We should write a document, or at least agree, on this too.

Gianluca and Loris

/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Guy Harris wrote:

Loris Degioanni wrote:

>Some genius had the idea of adding a new file (print-slow.c) to the
>repository few hours before the x.9.2 release, without at least trying
>to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't
>compile under Windows (even if it used to compile the night before the
>release).

There needs to be a developer's document of some sort that says "if you
add a source file to tcpdump, you need to add it to:

Makefile.in;

FILES;

INSTALL (well, that's not a *requirement*, but it's a good idea);

win32/prj/GNUmakefile;

win32/prj/WinDump.dsp;

Yes, in a genera way, we should a a pre-release building (and possibly
testing?) procedure, carried on by one person (or a limited group of
people) after the CVS has been locked.

and give examples of what's added to all those files.

Ethereal avoids problems such as these by not doing Win32 projects -
builds are done with command-line "nmake" - and having both the nmake
files and the Makefile.am files include Makefile.common files, so that
there's only *one* list of files.

The approach we've always used for our tools (WinDump, WinPcap, now
ntar) is two separate "makefiles" for Unix and Windows. This is more
complex for the developers of the tools, but makes life simple for the
users that download your source code. (Maybe it's lack of experience,
but I've always needed at least some hours to set-up the Ethereal build
envronment, while with WinDump it's a matter of seconds).
Moreover, Windows developers normally like to use the MS integrated IDEs
better than gcc/gdb/make.
However, if you think another approach is better, there's of course no
problem to switch to another solution.

Note also that WinDump and WinPcap have a cygnus makefile *too*, wich is
not integrated with the main autoconf/make, and which we (WinPcap team)
manitain. It would probably be a good idea to merge it into the main
build system.

Loris

It also catches at least some other problems by using Buildbot:

so at least some build problems get caught (if tcpdump were to do the
same, the builds should be done from tarballs generated by "make tar",
so that it catches files not added to FILES).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Jul 13, 2005, at 9:50 AM, Loris Degioanni wrote:

Yes, in a genera way, we should a a pre-release building (and
possibly testing?) procedure, carried on by one person (or a
limited group of people) after the CVS has been locked.

Note that this procedure needs to include at least one person with a
Windows development environment (and the time to start up that
environment, if it's not usually up and running), as well as one or
more UN*X environments; preferably, it should include a person with
both MSVC++ and Cygwin (and MinGW32?) development environments.

>and give examples of what's added to all those files.
>Ethereal avoids problems such as these by not doing Win32 projects
>- builds are done with command-line "nmake" - and having both the
>nmake files and the Makefile.am files include Makefile.common
>files, so that there's only *one* list of files.
>>
>
The approach we've always used for our tools (WinDump, WinPcap, now
ntar) is two separate "makefiles" for Unix and Windows. This is
more complex for the developers of the tools, but makes life simple
for the users that download your source code.

("We" here meaning the Ethereal developers)

Unfortunately, at least in our experience, the extra complexity
turned into extra bugs - people quite frequently added files to
Makefile.am but not Makefile.nmake (I don't remember whether any
developers mainly using Windows added to Makefile.nmake but not
Makefile.am or not). Those problems, at least, went away when we
went to a common Makefile.common used by both.

If there were a mechanism to generate the appropriate MSVC++ project
files from a description file that could either be included by
Makefile.am (or *be* Makefile.am), or to generate the MSVC++ project
files and the Makefile.am or Makefile.in file from a common
description file (using tools available in source form, not Windows-
only or Linux-only or S X-only or Solaris-only or binary tools),
that'd be useful, as long as we didn't lose any configure-script
functionality and as long as we could still use, at least on UN*X,
all the same "generate stuff at build time" techniques we use now
(i.e., as long as there's no loss of useful functionality in the
build process).

libpcap and tcpdump are less demanding, but they still require a fair
bit of configure-script fun.

(Maybe it's lack of experience, but I've always needed at least
some hours to set-up the Ethereal build envronment, while with
WinDump it's a matter of seconds).

Is that an issue of setting up the environment for MSVC++ (I vaguely
remember hearing of some .bat script that is used to set environment
variables for command-line builds), or of downloading and installing
libraries, headers, and tools, or something else? it's set up,
I've found that I can just do

nmake -f Makefile.nmake clean (so that if a header changed the
source files that depend on it change)
nmake -f Makefile.nmake

and the build works.

Moreover, Windows developers normally like to use the MS integrated
IDEs better than gcc/gdb/make.

You could, I guess, set it up as a "Makefile project".
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Tue, Jul 12, 2005 at 11:10:38PM -0700, Loris Degioanni wrote:
| Some genius had the idea of adding a new file (print-slow.c) to the
| repository few hours before the x.9.2 release, without at least trying
| to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
| under Windows (even if it used to compile the night before the release).

that was me - guilty;

| We already checked in a patch, are there plans for a x.9.3 release? If
| yes, could people stop to do breaking commits before it's done?

you could help me avoiding those things by writing up a document that
describes what files you need on windows to be touched / added;
i only test on freebsd and linux;

/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.