trac tickets and alternative build system

[Hauke Heibel]

Hi Adam,

Thanks for your reply. I am wondering how I should continue
developing. As said before, I have checked out your work though at
some point it would be nice if I could publish it such that you could
access it and follow my changes. I don't have much experience with
git, I am more familiar with hg. Nonetheless, I will of course use git
for this project since otherwise it will be a pain to reintegrate any
changes. What do you think about the idea that I create a working copy
of OpenSlide on GitHub? Or do you prefer a branch?

On Mon, Apr 26, 2010 at 10:02 PM, Adam Goode <agoode at andrew.cmu.edu> wrote:
> On 04/26/2010 11:50 AM, Hauke Heibel wrote:
>> I tried to submit a track ticket today though it seems to have failed.
>> But I can anyways be a little bit more verbose over here.
>
> Hmm, this should work. I just tested it. Did you solve the captcha?

Maybe it happened because I did not specify 'Milestone' nor 'Version'.

> I have used CMake before, I am not against using CMake for OpenSlide,
> but I would prefer to see how well it works for you first. I would even
> be open to including your CMake support in the repository, but secondary
> to the existing configure stuff, so that people could try it out.

Sounds great!

>> 1) the git repository is missing config.h.in (though it is present in
>> the tarball)
>
> Yes, that is a generated file and is not checked in. (Use autoreconf -i
> to generate it.)

So the typical workflow is

run 'autoreconf -i' --> creates config.h.in
run ./configure --> creates config.h

For CMake this is slightly different since I have to provide
config.h.in which is easy enough. CMake can then run tests and create
the actual config.h.

Also, as mentioned before I recognized that there are a bunch of
defines which are not used in your library. Do you think it makes
sense to break things down to a minimum of required defines? Or are
all of them needed in C99 projects?

>> 2) stdbool.h and inttypes.h are not available under MSVC
>
> Yes, these are C99 files.

Which is not a problem if I build the code as C++ code since then all
required types are available.

>> 4) PRId64 is not defined and I have no idea how to fix it.
>
> This is a C99 way to get the printf format string for a 64-bit signed
> number.

I am not sure but as far as I know the alternative on MSVC might be to
define PRId64 as %lld or something similar. Alternatively, I could use
the stringstream class from the standard lib.

>> 5) void __attribute ((constructor)) _openslide_init(void);
>>
>> The constructor attribute is not supported under MSCV. I temporarily
>> hacked around it by declaring the function as void
>> _openslide_init(void);
>
> Yeah, for VS, there must be some way to annotate functions to be run as
> DLL constructors. This can be abstracted in openslide-features.h like
> OPENSLIDE_PUBLIC is.

Hmm, this is probably going to be a little bit more difficult and I
have to do some research before proposing a solution.

>> 6) struct _openslide_cache_key key = { .x = x, .y = y, .layer = layer };
>
> Yup, another C99 thing.

After compiling a few more files, I found that you are also using this
syntax to create static variables (there is a struct holding function
pointers) which does not allow me to use a two step phase where I
first create an object and then assign the values. On my compiler this
works

struct _openslide_cache_key key = { x, y, layer };

though I think it is only working because of the newly introduced
C++0x initializer lists. The only portable solution is probably to add
a constructor taking the parameters.

I will keep you updated.

Regards,
Hauke