[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with furthe
Re: [Libcdio-devel] should libcdio be declared 0.91 as is or with further changes ?
Wed, 23 Oct 2013 13:11:50 +0100
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 . 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
> 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
> 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 , 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
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?