On 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 OS 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? Once 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.
