i wrestled with whether or not to put apr, libconfuse, expat in the ./srclib directory given that they are not modified in any way by us (just statically linked against). it makes sense that libmetrics would be in cvs since we are constantly modifying it.

in the past, developers and interested parties could simply bootstrap cvs and build ganglia. the only way to keep things the same is to have a complete ./srclib directory. when i checked out the apache cvs ./srclib i noticed they put everything there (for older versions but not newer versions of apache). otherwise, we will to instruct cvs users to download the correct version of apr, libconfuse, expat and drop them into the ./srclib directory before running "bootstrap". i'm happy to remove all but libmetrics from the ./srclib if you guys think that is a better idea.

the reason you are seeing that your local copy has been modified is because the time on your machine is not in sync with the sourceforge cvs server. when you update cvs, cvs syncs the timestamps of your files to the time on the cvs server which then causes autoconf/make/et al to recreate files (such as Makefile.in and aclocal.m4). that is a problem given that it is possible (likely) that the toolchain used to create libraries in ./srclib are uniquely different than the ganglia distribution in general.

the workaround is to run something like the following before you run "bootstrap"

% touch /tmp/foo && find . -exec touch -r /tmp/foo {} \;

this ensures that all files in your local repository are set to the same local time so autoconf, automake, etc will not run when you bootstrap (unless you modified files).

i would going to add the command to the "bootstrap" script but i wasn't sure how to write a portable command that will do the right thing on all ganglia platforms.

let me know what solution you think wouuld work best for the team. remove the libraries from ./srlib or update bootstrap to ensure local timestamps (thus preventing the autoconf/automake/etc madness) or some other solution...

-matt





Martin Knoblauch wrote:
Hi Matt,

 being confused again :-) When doing the following after a fresh
checkout of the 2.6.0 sources from CVS, I find the following files
marked as "Locally Modified". This seems kind of wrong to me. If they
are part of the repository, they should not be modified by the
toolchain. If they are supposed to be generated by the toolchain, they
should not be in the repository.

 The real problem comes when doing checkins from the monitor_core root
directory. In that case the mentioned files are being sent back to the
repository.

Merry XMas and A Happy New Year
Martin

$ ./bootstrap
$ ./configure
$ make
$ cvs -z3 -q status | grep Status: | grep Local
File: Makefile.in       Status: Locally Modified
File: aclocal.m4        Status: Locally Modified
File: configure         Status: Locally Modified
File: Makefile.in       Status: Locally Modified
File: Makefile.in       Status: Locally Modified
File: Makefile.in       Status: Locally Modified
File: Makefile.in       Status: Locally Modified
File: Makefile.in       Status: Locally Modified
bash-2.05b$ cvs -z3 -q update -dP
M srclib/confuse/Makefile.in
M srclib/confuse/aclocal.m4
M srclib/confuse/configure
M srclib/confuse/doc/Makefile.in
M srclib/confuse/examples/Makefile.in
M srclib/confuse/m4/Makefile.in
M srclib/confuse/src/Makefile.in
M srclib/confuse/tests/Makefile.in





=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de

--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'

   They that can give up essential liberty to obtain a little
      temporary safety deserve neither liberty nor safety.
  --Benjamin Franklin, Historical Review of Pennsylvania, 1759

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to