Thanks to the amazing work by Peter Hull, Allegro is now packaged by NuGet, a MSVC-supported package manager!

If you have MSVC 2015, you can try it out by following the tutorial.

We'll be adding support for more MSVC versions (probably 2012) and probably new build types (a statically linked dynamic runtime version at the very least) at some later point.

1. Well, first things first, that's awesome.

2. After having to clear 5 Gigs from my hard drive for MSVC 2015, I can't seem to find Empty Project {"name":"609972","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0f5e9d723fbd0a0a8ed4f0cc2d85797.png","w":1100,"h":800,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/0\/a0f5e9d723fbd0a0a8ed4f0cc2d85797"}

3. How does one go about getting a package on NuGet? Is it a lot of work?

2. Haha! Didn't think I'd need to add a tutorial for that Yes, you'll need to install the C++ tools (I'm sure I recall an option for that during installation). Indeed, MSVC is a terrible space hog.

3. Getting it there is easy (they don't even sign packages like Ubuntu PPAs do...), but creating one will take a bit of work.

I do not like Windows, but I really like this news. Peter Hull gets an extra big Christmas bonus this year.

Is this a full static build of Allegro, or DLL? I'm currently including self-built static Allegro monoliths in the minisphere Git repo and it would be nice to be able to quit doing that.

That's really fantastic. Very well done, Peter!

FYI, I've found NuGet to be more trouble than its worth in professional work. We use it to manage several packages from .NET libraries and frameworks to JavaScript libraries. It's generally quite a mess. And we haven't figured out the right incantation to mix it with version control... This is literally a Windows-style package manager... It lacks many of the things that make package repositories Just Work(tm). It's generally a poor way to pull in JavaScript library updates. For Allegro's purposes I think it will solve the problem quite nicely!

It comes with a non-monolith release, non-monolith debug and a monolith static release (since there's no practical difference between monolith and non-monolith static builds) builds. The release builds statically link the runtime, but as per a request in a different thread there'll probably be a dynamically linked runtime static release build version at some point.

I think SL is being modest, as usual. He knocked all the rough edges off my package definition and made it usable.

Couple of points:

• Unlike Linux where the packaging is fundamental to the concept of a 'Linux Distribution', Nuget feels a bit of an afterthought. I have a horrible feeling MS is not 100% behind it though it does seem to be gaining popularity at the moment.

• It seems to handle different tool sets and platforms by just including all possible variants in the same package - one for each version of Visual Studio times each debug/release variant times each processor. This makes for big packages which AFAICS are copied in their entirety into each project that uses them.

• The docs are a bit sketchy so anything I say above may be wrong!

Thanks all,
Pete

Eh, afterthought or not it still beats including the .lib files in your Git repo directly.

I tried it, works well. Should be really helpful to get people into allegro development easier on windows.

Tried it .. perfect !! The easiest way to get started on Windows

How do the Allegro packages/versions get updated?

I build them and then upload them on nuget.org.

I have tried out creating a few projects using NuGet.

I get an access violation (Exception thrown at 0x00000000 in test.exe: 0xC0000005: Access violation executing location 0x00000000.), when I put this code in main():

al_init();
al_init_image_addon();
al_set_physfs_file_interface();
al_load_bitmap("data/tiles.png");

When I comment out al_set_physfs_file_interface(), I get no access violation.

Is this a bug or some setting I must do in my project because I'm using NuGet?

Nuget only copies the files and makes sure the project settings reference them, so you shouldn't have to do anything different.

I would first check you aren't accidentally mixing in any other versions of Allegro that you have installed, and if that's not the problem, is it possible for you to zip up a minimal example project and post it here, or file an issue on https://github.com/SiegeLord/allegro_winpkg/issues ?

Thanks

You never called PHYSFS_init.

Oh. Me stupid.

The "allegro-debug.pdb" symbol file is missing and/or not deployed with the NuGet package so when a program crashes it's impossible to trace them back to figure out what was passed to Allegro's functions to figure out what was wrong.

Hmm... we never actually distributed pdb files before. The debug versions are sort of more for triggering the asserts inside allegro, rather than necessarily backtracing into it. Currently our build system doesn't install them correctly (and it doesn't appear that it builds them correctly for the monolith library), but if we fix that, we could probably distribute them.

They are a bit large though, hah.

Be careful about distributing PDBs - they include absolute path information (to help MSVC locate the original source files).

And yes, they do tend to be huge.

The reason I ask is because I'm currently having an issue of a crash-on-close where something has gone out of scope and/or cleaned up via RAII smart pointers and allegro tries to handle it after returning from main. All I get is "Could not find allegro-debug.pdb" from Visual Studio 2015 when stepping through. Digging through (at most) 30,000 lines of code to find where my program is passing an expired value is going to take forever.

So, to do this we just have to correctly name the package (Allegro.symbols.nupkg) and the NuGet/VS system will automatically make the link?
(Based on https://docs.nuget.org/create/creating-and-publishing-a-symbol-package)

Most of my experience in Windows/Visual Studio land is with .NET code so maybe it's different, but typically when you build a foo.dll using a Debug profile there is a foo.pdb created alongside it. I'm curious if this "allegro-debug.pdb" is a literal error message or is an approximation, and if it's exact then what symbols within the package match "allegro-debug"?

For completeness, here's the exact error after the program attempts to return from main:

"Exception thrown at 0x577E3E67 (allegro-debug-5.1.dll) in Engine.exe: 0xC0000005: Access violation reading location 0x00000000."

When I select "Break" from the available buttons I get:

"No Symbols Loaded (tab name)
allegro-debug.pdb not loaded (title)

allegro--debug.pdb contains the debug information required to find the source for the module allegro-debug-5.1.dll

Module Information
Version: [blank]
Original Location: [Path to Output folder for Debug Configuration]\allegro-debug-5.1.dll"

It's obvious that a heap-allocated variable has gone out of scope and cleaned itself up (I'm using C++11 smart pointers) and then Allegro tried to do some cleanup with it but without a Call Stack or symbols available I have no idea which variable went out of scope nor which function tried to access it.

EDIT

After deleting the output folders and rebuilding to make sure I have the correct DLLs loaded (I still had a few of the 5.0.10 DLLs in them, now they are all 5.1) I still get the same error.

Have you correctly implemented copy constructors for your 'smart' objects? You can easily add in a printf statement here and there to see what kind of object it is, or add in a divide by zero if you detect a double free to get a breakpoint.

If you're copying objects naively (shallow copy), that could easily be the source of a double free when the original is destroyed and then the copy goes out of scope it will free it again. That's my guess without looking at any code.

I've figured out the issue. I was not manually resetting (a call to the smart pointer's reset function) a file-scope smart pointer during the user-defined cleanup phase. If that step is missed, the C++ Standard says destruction of the smart pointers takes place during std::exit. Since Allegro has hooked into exit via a call to std::atexit it effectively shuts down before exit is called. Then any smart pointers try to use the custom deleters pointing to Allegro functions...which no longer work. Crash with accessing a no-man's-land (0xDDDDDDD) or null pointer address.

I love programming. I hate debugging.

Bambam would say that's what you get for using globals.

And as an aside, if you're manually calling reset, why are you using a smart pointer in the first place?

Because they are a great feature to have...as long as a third party library does not hook into the exit function and shutdown the use of the custom deleters.

With this issue resolved I now declare the NuGet package awesome and easy to use and set up. PDBs would still be a nice feature though.

(P.S. I can't seem to find the Quote button on this forum software)

You're welcome to shutdown allegro manually, by avoiding the allegro atexit shutdown by using al_install_system and then calling al_uninstall_system after your globals get destroyed.

There is no quote button, as I found out a while back. You have to greentext:

> Some text to quote

As for this:

I must be weird. I'll get a bug report or come across a bug myself, I rub my hands together in an excited "let's get to work!" way, and fire up the debugger. I probably have more fun debugging than I do writing the original (buggy ) code.

That said, the type of bug you had to deal with isn't very fun, even for me.