(fixed) DAllegro5 batch fails on paths with spaces/hyphens

[Forestidia86]

Just for completeness:
SiegeLord actually has provided a tool/batch file that creates Allegro libs from the DLLs. (Nevertheless good to know how to do it manually just in case.)

Just an addition: It looks like the directory path where the Allegro DLLs are situated shouldn't have something like spaces or hyphens ("-") for the batch file to work properly.

[Simon]

shouldn't have something like spaces or hyphens ("-")

Should be reported directly against SiegeLord's repository. I'll forward it.

This is typically a bug in the script, the variable expansions should be enquoted, and the path shouldn't be split by hyphen. I don't know enough Windows batch to fix this.

-- Simon

[Forestidia86]

From what I've read my guess is that it comes from using DPNa (Drive, Path, Name (of a)) instead of just Na.
But maybe SiegeLord has a reason to use the full path instead of only the name. I really have no understanding of batch file scripting myself.

[Forestidia86]

Only another thing connected to that:
The same issue arises if you have e.g. something like allegro-debug-5.2.dll. It then only creates allegro.lib since it goes only to the first hyphen (as far as I've tested and maybe arising from "tokens=1 delims=-" ). That could be a problem if you have have release and debug dlls in the same folder since for allegro-5.2.dll as well as for allegro-debug-5.2.dll allegro.lib is created probably one overwriting the other. That was one thing that threw me off in the course of trying to run against Allegro debug libraries since I didn't know that at that time.
Couldn't the debug liberaries have an underscore rather than a hyphen like eg. allegro_debug-5.2.dll?

[Simon]

Couldn't the debug liberaries have an underscore rather than a hyphen like eg. allegro_debug-5.2.dll?

You can name any file however you like.

The real problems:

• What governs which DLL is required at runtime? Example of what won't work: Have DLL, then generate LIB from DLL, then invent naming scheme and rename both the DLL and LIB according to this scheme. Build Lix and link against the LIB. When you try to run Lix, it crashes because it wants the un-renamed DLL.
• Is the underscore naming conventional? Assume that we change the dubfile for linking against debugging Allegro libraries, then it would be nice to have the debugging libraries named the same on every system. I suppose -debug- is common and _debug- is not.

If the script generates weird filenames, fix the script. Apparently the script works only for release libraries in certain paths. Ideally, the script builds debugging LIBs from debugging DLLs and release LIBs from release DLLs.

Renaming the files would produce a nonstandard build environment; you can do that, but you must assume that everybody else will not support it.

-- Simon

[Forestidia86]

Another point where people can trip over:
When installing dmd with the installer on Win it wanted to install another external big program for 64bit-support.
I always declined that and got a warning that there is no 64bit support then but for Lix it was sufficient without that (program). Lix builds fine even without.

[Simon]

Good idea, I've added that to the docs.

-- Simon

[Forestidia86]

Just for completeness:
SiegeLord actually has provided a tool/batch file that creates Allegro libs from the DLLs. (Nevertheless good to know how to do it manually just in case.)

Just an addition: It looks like the directory path where the Allegro DLLs are situated shouldn't have something like spaces or hyphens ("-") for the batch file to work properly.

Hm, if it is not dealt with, maybe a short notice to not have hyphens or spaces in file path.
What really could confuse is when you have hyphens in the file path. Because then it likely gives no error message and creates a lib but not in a way you want.

Example:
Let's say you have a file path without hypens or spaces so far.
Then create folder test-5.
Put allegro DLLs, implib.exe and the batch file in there.
Start the batch file.
=>
test.lib is created and put in the folder above.

[Simon]

This should be reported against DAllegro 5, not against Lix. I've forwarded it.

I don't have a Windows machine to test scripts, thus I can't fix this one myself. Since it's going to be in DAllegro 5 for a while, I'll warn about it in Lix's build docs.

-- Simon

[Forestidia86]

This should be reported against DAllegro 5, not against Lix. I've forwarded it.

Well, the problem occured to me in the context of Lix. And DAllegro 5 problems are technically Lix problems as well at least to the extent Lix uses it.
Since I pointed to the batch file I felt responsible to inform that there seem to be problems/that it has a restrictive use.
To be clear: personally I know that there is a problem and how to omit it, so I'm the last person that need the file to be fixed.
But the clarity of the build instructions may suffer from it and that was what my originial post and my last post were mainly about not about the issue with the batch file itself.
But in the future I will think twice if I report an issue.

[Simon]

I agree with everything, including that you push for a change in the build instructions, except your conclusion:

But in the future I will think twice if I report an issue.

Always report if your hunch is that something is wrong around Lix. Please continue, you have excellent reports. The documentation clearly belongs to Lix, and it shouldn't point to dangerous scripts without explanation. 100 % agree that I should either explain the bug or not point to the script.

At first, I thought you were pushing me to report against DAllegro5. You can see from the chatlogs that I was confused, I asked: What do you want me to do? For me, it was common sense to document the bug as far upstream as possible. I didn't realize at first that you wanted me to document it in the Lix build docs, which is a good idea here.

Thus, please continue to report liberally against Lix.

-- Simon

[Simon]

Fixed upstream by SiegeLord. Thanks for the report!

-- Simon