announcing abuild version 1.0.1
From: Jay Berkenbilt (ejbabuild.org)
Date: Fri, 30 May 2008 15:20:27 -0700 (PDT)
(All members of this list are still current or former Argon employees.
I will be making a separate announcement to the internal Argon list
with details about its internal release which should happen next
week.)

I have released abuild 1.0.1 and have put the release on the
sourceforge site, which you can reach from www.abuild.org.  Here are
the release notes.  Thanks to all those who contributed ideas or
fixes.

--Jay


1.0.1: May 29, 2008

* Minor updates to test suite to make it more portable. In particular,
  abuild's test suite is now known to pass on Solaris 8.

* Internal code change: avoid using boost regular expression objects
  across multiple threads in hopes of solving occasional assertion
  failures inside the boost library when running with multiple threads
  under Windows.

* Abuild was previously passing a JAR file rather than a directory to
  ant's -lib argument. This has been corrected. (Thanks for the
  problem report from Craig Pell.)

* If AUTOCONFIGH is not set, abuild's autoconf rules will not run
  autoheader. This makes it possible to create an autoconf build item
  without generating a header file if desired.

* When autoconf invokes the compiler, it now honors any flags or
  includes set by dependent build items. (Thanks for the problem
  report from Joe Davidson.)

* Include two small patches to make abuild build properly in MacOS
  Darwin. (Thanks for the patches from Joe Davidson.)

* With --verbose, abuild now prints the backend command that is
  invoking.  (Thanks for the suggestion from Craig Pell.)

* Documentation updated to add autoconf, automake, and GNU diffutils,
  and gcc configured with gnu ld to the list of system requirements.

* Abuild now mentions when nothing is built but some native build
  items were skipped due to lack of available platforms. Hopefully
  this will reduce confusion when Windows users without any valid
  compilers or cygwin perl type abuild and don't get any output. Also,
  when --verbose is specified, abuild always mentions when it skips
  any build item because of lack of build platforms.

* Bug fix: if tree A contained a plugin but did not use it, tree B had
  A as an external and used the plugin, and tree C had A and B in that
  order as externals and did not use the plugin, C would have not
  realize that the plugin was a plugin in any tree. This would cause a
  segmentation fault when loading the interface. This problem has been
  corrected because abuild now has a more robust way of keeping track
  of whether a given build item is ever a plugin.

* Enhancement: When the abuild.main-class property is set in
  Abuild.properties, abuild now sets the Main-Class attribute in the
  JAR file's manifest. This doesn't solve the problem of adding custom
  attributes to manifest files in the general case, but it does
  address the most common situation. Thanks to Craig Pell for
  providing an implementation.

* When building with Visual C++, embed the manifest file, if any, into
  the executable or dll file. Thanks to Matt Nassr for the suggestion
  and pointer to the relevant information.

* Temporary change: for abuild version 1.0.1, the environment variable
  ABUILD_FORCE_32BIT may be set to the value 1 to force abuild to
  generate 32-bit code on 64-bit platforms under certain conditions.
  Specifically, on a ppc64 platform, abuild will pass -m32 to gcc and
  will use ppc as the CPU type in the platform string. Likewise, on an
  x86_64 platform, abuild will pass -m32 to gcc and will use ix86 as
  the CPU type in the platform string. Note that abuild will not
  otherwise override the type of object file generated by your
  compiler based on the platform string. This means if you are
  building on a 64-bit system with a compiler that generates 32-bit
  object files, abuild will happily create 32-bit object files in a
  directory whose name suggests 64-bit code. (This is the case on Red
  Hat's ppc64 distribution at least with Red Hat Enterprise Linux 4
  and 5.) This change is temporary and may be removed in a future
  release in favor of a more robust solution for generating both
  32-bit code and 64-bit code on 64-bit systems.
  • (no other messages in thread)

Results generated by Tiger Technologies using MHonArc.