Closed GoogleCodeExporter closed 8 years ago
Hi Patrick,
I needed to think a bit about these requests, so now my thoughts on the items
below
- naming convention
Although the suggested naming convention regarding debug builds ('d') is a known
practice, it's not used in the underlying libraries (APR and Sofia). Also,
considering the current number of integrations and deployments, I don't think
it'd be
reasonable to change the names of the libraries at the moment.
- resource file(s)
In the meantime, I agree that resource files might be indeed helpful and will
try to
add them as we go along.
Regards,
Arsen
Original comment by achalo...@gmail.com
on 13 Apr 2010 at 11:55
I have built code under Windows for many years and I have never felt the need
to
have different names for the two types of configurations. The executable or
library
files associated with each configuration reside or should reside in separate
folders, if one follows Visual Studio settings. Furthermore, the running
binaries
can "learn" the location where they were started from and log it.
The APR dlls and pthreadVC2.dll have the version information already embedded.
It is
true that Sofia-SIP does not. UniMRCP gives us static libraries to link to our
applications, so the requirement does not apply. So, I guess ultimately, the
responsibility of including the version information falls mostly on our user
applications...
Just my guess.
Original comment by Curat...@gmail.com
on 15 May 2010 at 10:40
I have added libunimrcpclient.rc and libunimrcpserver.rc resource files in
r1712.
This is an alternate way to retrieve the version information and clearly it
falls to
actual user applications which method to use.
Suggestions are welcome.
Original comment by achalo...@gmail.com
on 25 May 2010 at 7:02
Hi Arsen,
thank you for adding these resource files.
However, i don't understand how this information could be retrieved at user
applications level.
Could you please clarify your point of view ?
Regards,
Patrick
Original comment by pnune...@gmail.com
on 26 May 2010 at 10:23
Hi Patrick,
Well, I assumed you had some use cases in mind suggesting to add windows native
resource files. However, if you have no particular reason to use them, you
probably
don't even need this change. As Vlad properly outlines in comment 2, UniMRCP
provides
static libraries for integration and version information is always available at
build
time through build\uni_version.h header file. And I agree that the rest is up to
actual user applications.
On the other side, resource files still might be helpful. This is a windows
native
format at least.
See the following link on how to obtain that version information
http://msdn.microsoft.com/en-us/library/ms646981%28VS.85%29.aspx
Regards,
Arsen
Original comment by achalo...@gmail.com
on 26 May 2010 at 12:51
Hi Arsen,
Sorry, i think my request was misunderstood.
Purpose of my request was to ask for embedding the version information into
each exe
file so that it may be available without launching the program.
On windows, this information could be available by right clicking on the exe
file,
then selecting properties, tab version.
I think this could be at least helpful for unimrcpserver, umc and unimrcpclient
programs.
Regards,
Patrick
Original comment by pnune...@gmail.com
on 26 May 2010 at 1:37
Understood! Done in r1714.
Original comment by achalo...@gmail.com
on 26 May 2010 at 7:26
Original issue reported on code.google.com by
pnune...@gmail.com
on 12 Apr 2010 at 2:27