Re: [Ekiga-devel-list] ekiga.rc
- From: Peter Robinson <pbrobinson gmail com>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] ekiga.rc
- Date: Mon, 20 Apr 2009 18:12:13 +0100
>>>>>> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]