>>>>>> Is there a way to move ekiga.rc from root to win32? >>>>> >>>>> 1) git mv ekiga.rc win32/ >>>>> 2) make sure any file referencing ekiga.rc now searches for it in >>>>> win32/ >>>>> >>>>> Snark >>>> >>>> Could you please rename it so that the basename is distinctive, e.g. >>>> ekiga-rc.rc ? I ask this because eventually we can include compilation >>>> of the resources into the autoconf/libtool make process and then an >>>> ekiga.o file would be a bit dangerous I think. Additionally VALUE >>>> "SpecialBuild", CVS_VERSION in the resource file is a bit outdated. Now >>>> an EKIGA_REVISION is defined in src/revision.h . See attached patch as >>>> an example for how one could handle the Win32 resources. >>> >>> Note that ekiga uses git now, so src/Makefile.am info about revision.h is >>> obsolete... Is it interesting to resuscitate it? >>> >>> -- >>> Eugen >> >> Yes, I have seen that. I am still testing. Would something like >> #define EKIGA_REVISION "EKIGA_3_2_0-80-g80bf6d3" be acceptable in >> revisioin.h? It is based on the output of git describe, the 80th >> revision of tag EKIGA_3_2_0 I guess. > > For my snapshots, I use only the date in the .deb file name (see > http://snapshots.ekiga.net/snapshots/debian/). Users can know the version > (the date) with 'dpkg -l' afterwards. Wouldn't this be sufficient for > windows snapshots too? (Simpler is better :o))
I would personally prefer the git version rather than the date version as there could be multiple different versions of ekiga on a single day dependant on the amount of commits. By using the git rev you know exactly what the build was based upon so it makes it easier from a debug and recreation of the problem perpective. Regards, Peter _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list