On Fr, 2011-02-04 at 21:54 +0000, Ove Kaaven wrote: > Den 04. feb. 2011 22:26, skrev Ove Kaaven: > > Investigating, I found that src/Makefile.am in git is different from > > src/Makefile.am in the tarballs, having a different list of backends and > > templates. Why would there be a non-working makefile in git, but a > > working one in the tarballs? > > Hmm, it seems this makefile is not actually in git, but somehow git > didn't tell me that. Right, all other version systems I know would > report "file unknown" instead of "nope, no differences" when I ask it to > compare the local file with the repository, but nooo, not git... I guess > it really wants people like me, who wants things to work *without* > headbanging, to continue to hate it...
That's indeed odd. > Well, I think I found the answer: we're apparently supposed to rerun the > autogen script whenever we update the git checkout, it doesn't > automatically reconfigure itself like most other automake-based projects > do, for some reason... It does re-generate the make files when files change during a git checkout. It does not regenerate them when files are added or removed. This is somewhere in that grey area between "missing feature" and "bug". I can check how difficult it would be to fix. The reason for this additional layer on top of standard autotools is that I found no better way to generated certain lists dynamically: - backend subdirs - template files Standard practice is to manually list stuff in Makefile.am and/or configure.ac. The original goal was that people can add a src/backend directory *without* having to modify any additional files - admittedly in the age of distributed version control systems this is less of an issue. For the other files it is simply laziness. Why do it manually (and inevitably forget about it at some point...) when a "find" can do it? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
