Is HAVE_CONFIG_H still needed?

[Vollstrecker]

If I see this correct, when building with autotools, config.h is always there. Problems could be plattforms that don't support them. On Win, we have project file that are hardly outdated, and I really would prefer to just remove them, as with cmake they get generated in useable form. If cmake is used, config.h is on windows available, too. I don't know about Mac, but there is somewhere in the issues stated that the project for this is also outdated.

So in my eyes we could remove the HAVE_CONFIG_H define, which could make the commands a bit more readable, and get rid of some code doubling at the same time.

[gonosztopi]

Actually even the Visual Studio projects have config.h and thus HAVE_CONFIG_H defined. 😎

Problems could be plattforms that don't support them.

Most likely they have a way to generate them if needed (like even Visual Studio can generate one, though with preset content).

So in my eyes we could remove the HAVE_CONFIG_H define, which could make the commands a bit more readable, and get rid of some code doubling at the same time.

Go ahead!

[Vollstrecker]

Done

[Vollstrecker]

Oh, and while we're at the cleanup. The cryptopp-prefix: Why define something when all related files are in one dir. Wouldn't it be easier to just have an -I for this?

[gonosztopi]

By the way, do you expect to find the sources (like current VS projects do) or a pre-built library?

[Vollstrecker]

But are you sure there isn't a system header on every supported platform that matches the name of a header we want to
include from cryptopp

From that point nope. This always can happen i.e. we have Logger.h and Types.h in our source what sounds very generic to me, at least more than rsa.h. This just works because of the ordering of the -I statements.

It should be ../cryptopp if you want to follow the current directory structure required by the VS projects.

Jep, I just want a generic solution. I've built their VS-Solution, but they didn't include some install-target. I want to avoid to have to give the users instructions like "Copy headers and libs from different locations to here". And, given, it's not very common, I don't want them to double the locations of the libs they have already.

just follow the normal detection route based on the cmake equivalent of --with-crypto-prefix.

That's the point. As there is no standard-way when there is no module shipped, I have to write it. And fiddling out the output-dirs of their VS-Solution, plus some generic places, plus different names or locations for Debug/Release and Static/Dynamic results in a monster. Given, for the headers this isn't that much, as it's just that one prefix, but it's the overall concept on win that's pissing me.

Anyway, you always need to specify a prefix unless you're using a POSIX-like environment, such as MSYS or Cygwin.

I don't get that difference. We need a location on all plattforms. POSIX has just the advance, that there are standard locations where we most likely find something.

Just let it default to .. when generating for VS and you're done.

I hardly doubt that I'll find ../rsa.h anywhere beside a subdir of cryptopp sources.

By the way, do you expect to find the sources (like current VS projects do) or a pre-built library?

Always pre-built and the corresponding headers. Otherwise I would have to replacate their build-process, which is just not our job. For using their sources I started CmDaB, that's integrating their build into ours, but therefor (at least for now) they need to support cmake, too. There is a project that maintains the cmake-stuff for cryptopp which was first a part of their sources but got thrown out as cmake doesn't support all plattforms cryptopp support. A decision I don't find reasonable in any way, but we have to deal with it. This project needs some adjustments before it's working like expected, but I'm already working with them on it.

[gonosztopi]

And yes, that's why I renamed ours to amule-config.h

That didn't turn out as good as it was planned. The included gettext wants to include config.h, so as long as we ship a gettext implementation with aMule we need to stay with that name.

[Vollstrecker]

I didn't even know we ship a gettext.
But if we ship it, it should be changeable.
How is usage of that triggered?

[gonosztopi]

How is usage of that triggered?

Either configure not finding a GNU compatible gettext or the user giving --with-included-gettext to configure.

if we ship it, it should be changeable.

It lives in the intl subdirectory, which is regenerated every time autogen.sh runs. Of course we could add our hacks to autogen, but I think just staying with config.h is easier and less error-prone. And since we've never had problems with that name, it won't harm to leave it as-is.