Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?

[Natalia Portillo]

Hi Pete,

El 22/10/2013, a las 20:11, Pete Batard <address@hidden> escribió:

> Hi Natalia,
> 
> On 2013.10.21 22:52, Natalia Portillo wrote:
>> Do you have knowledge of VS precompilation scripts?
>> 
>> And postcompilation?
> 
> I've done some very limited work with Pre and Post build events in VS2012 for 
> libwdi, where I wanted Intellisense to avoid scanning a large autogenerated 
> include (to stop it from hogging the CPU when doing so), as well as execute 
> the host-build executable that generates that include.
> 
> You can take a look at the PreBuiltEvent and PostBuildEvent from [1]. The Pre 
> task runs the following set of commands before the build:
> 
> cd $(ProjectDir)\..
> if exist embedded.no_is ren embedded.no_is embedded.h
> embedder embedded.h
> 
> Basically, it uses one of the various project variables, here $(ProjectDir), 
> to switch to the source directory, then renames a file and finally calls on a 
> previously generated executable (embedder.exe) to updates the embedded.h 
> include
> 
> I think the more troublesome part is figuring out the various variable names 
> that Visual Studio makes available, as the rest is equivalent to writing a 
> batch file.

I’ll check about it this weekend.

>> We are having problems on how to make the work that usually autoconf does, 
>> and how to auto run test once compiled.
> 
> Hopefully the above will help.
> 
> In your case, in the Post task, you probably want to 'cd' to the directory 
> that contains the generated test executables (I think there's an MS variable 
> for the build dir), then check if the test executable exists before launching 
> it.
> 
> I believe that the DOS errorlevel generated by any command from these scripts 
> is used by the Pre/Post step to determine if the operation was successful, 
> and flag an error if it wasn't.
> 
> There may also be other ways to run a test suite within Visual Studio.
> 
>> Also i need to get it to create a dynamic library not just the static one as 
>> it is doing, but this is not so much of a priority.
> 
> I don't have a good answer to that one. Right now, in the Visual Studio 
> projects I have, that create a library, I maintain two MSVC projects: one for 
> the static library and one for the DLL.
> 
> For instance, if you look at libwdi [3], you'll see a libwdi_dll.vcxproj and 
> a libwdi_static.vcxproj.
> The global MSVC solution is set to only use one of those (in this case the 
> static), leaving the user to generate the DLL manually, if they need it.
> 
> Still, I wouldn't mind finding a solution, that doesn't involve manually 
> keeping 2 project files in sync (and that isn't based on using CMake, as the 
> requirement of CMake to run on a platform with the target MSVC installed, 
> just to generate a project file compatible with that target, is too 
> restricting on cross-platform projects, where a maintainer using Linux may 
> want to generate a set of ready-to-use static MSVC project files for a 
> release)…
> 

Yes I expected to need another project.

I’m worried what will happen when a new file.c is added to the project on the 
UNIX side, as probably no one will care to add the same file to the vcxproj 
file (just a plain XML, indeed I made them all outside of VS), and will get out 
of sync again.

For the rest of the 0.91, wait!

I’ve been heavily working monday and tuesday, with a friend that wants to stay 
anonymous, and we have almost corrected the Mac OS X driver, and found a bug in 
the inner guts of libcdio.

Right now if you call get_devices() or get_default_device() it is making an 
open() on the drive, library-wide. Not so much of a problem in Linux or Win32, 
but opened drives in Mac OS X disappear from the list of available drives, so 
anything that comes later than the get() functions will fail in Mac OS X. As I 
understood it, get() functions should merely get a list of available drive 
paths, not open any of them at all, or even init the drive, so this should be 
corrected, isn’t it?

Regards,
Natalia Portillo