https://bugs.gentoo.org/show_bug.cgi?id=423743
"The Makefile.am claims including GLIB_LIBS when linking wireshark is
unnecessary, because wireshark links to GTK_LIBS which is a superset.
It is not actually a superset: gmodule is included in GLIB_LIBS but
not in GTK_LIBS (unless accidentally on older glibs/gtks)."
so we must explicitly link with GLIB_LIBS.
Update the comment to reflect that - and to reflect that GTK+ doesn't
necessarily run atop X11 - while we're at it.
Fixes bug 7427.
#BACKPORT
svn path=/trunk/; revision=43561
checking, so if a UI library changes Wireshark won't be relinked with
it. Revert the change that made them platform-dependent; we may end up
having to have separate targets for GTK+ Wireshark and Qt Wireshark.
svn path=/trunk/; revision=43384
from makefiles (and thus from the buildbot).
The intention is to be able to tell when a human is running the tool so we
can provide more code-review guidance.
As a starter, enable the "too many proto_tree_add_text() calls" check when
a human is running the tool.
svn path=/trunk/; revision=41943
having something in wireshark_LDADD that's filled in by the configure
script means that the items referred to by that string aren't treated as
dependencies.
svn path=/trunk/; revision=41709
UI library in the GTK+ directory.
List the moc-generated and rcc-generated files as generated files.
Add main_window.ui as an EXTRA_DIST file. Sort the EXTRA_DIST list.
svn path=/trunk/; revision=41658
so we need to link libui *after* libgtkui. (It worked on Mac OS X, but
the OS X linker might do things differently from the GNU linker.)
svn path=/trunk/; revision=41063
object files from all the source files in the ui directory (but not in
its subdirectories), and link the programs that need it with them.
This cleans things up a little bit, and may also fix the Windows build.
svn path=/trunk/; revision=41061
retrieve our SVN revision in releases.
Use make-version.pl to set all version information. Be more explicit
about the tasks it performs:
- Fetching the SVN revision which corresponds to our code. The
revision can be fetched via "svn info", "git svn info", SubWCRev",
config.nmake, or by prodding .svn.
- Setting the version numbers (the "major.minor.micro" triplet).
- Setting the release information (revision/build number, local build
identifier)
Remove the "is_release" configuration option and dist-hook target.
When run with a "--set-*" option or no options make sure we leave a
valid svnversion.h behind.
svn path=/trunk/; revision=39891
XXX - "svnversion.h" is distributed in the release tarball; should
we be deleting it with "make clean", or should we only do that with
"make maintainer-clean"?
is probably "we should only do that with "make maintainer-clean""; see
http://www.wireshark.org/lists/wireshark-dev/201111/msg00027.html
and followups.
svn path=/trunk/; revision=39716
SVN version, indicate that the SVN version is unknown. This puts back the fix
for bug 1413.
Add a new version.conf option for make-version which tell is "this is a build
from a release tarball." When that option is present do not try to use SVN
to determine the SVN version, just use whatever SVN information shipped in the
tarball.
If version.conf is present in the source tree (as it is only in the release
branches), deliver it in the source tarball but only after setting the "this
is a release tarball" option.
All of this means that that builds from release-branch tarballs will report
the SVN version of the release tarball rather than "unknown." This addresses
the issue reported in
http://ask.wireshark.org/questions/5376/wireshark-161-title-shows-svn-rev-unknown-from-unknown
Builds from trunk (including the source tarballs) will continue to report that
the SVN version is unknown. (Maybe that, too, should be changed?)
svn path=/trunk/; revision=38933