Re: [AD] Don't use Devpaks

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Hi Andrew,
A few points have been raised here. I've not used Dev-C++ since probably about 2002 so I can't answer everything, but I will jump in and hopefully someone else can address the rest.
1. I looked on http://www.bloodshed.net/ and I can't see any versions newer than 2005's 4.9.9.2. Is there a newer link?
2. GCC's command line option -lXYZ means 'look for a file called libXYZ.ext in the library directories' - so if you want  liballegro-4.2.2-monolith-mt then -lallegro-4.2.2-monolith-mt is correct. The extension .a is a static library, I think MinGW can also link direct to a .dll.
3. All C programs need to link to a runtime library, Microsoft's is called msvcrt-something (or at least has been called that, they changed it recently IIRC). The point of MinGW was that it could use Microsoft's runtime, compared to something like Cygwin which has to implement its own runtime. So seeing references to msvc are not unexpected.
4. Not sure about the error with the code you posted, I'll have a think.
5. Allegro 4 predates 64-bit anything so I'm not surprised there's only a 32-bit version. I don't see why it couldn't be compiled as 64-bit though.

Overall it looks to me like the Allegro devpaks have gone a bit stale and, indeed, that Dev C++ has gone a bit stale. I don't know who the package maintainer is (mpxd at live dot com ), does anyone else?

I would echo SL's comment and recommend using Visual Studio Community and the Nuget packages; they are bang up to date and I'd say easier to work with than anything we have for Mac or Linux.

Cheers,
Pete


On Sun, 8 May 2016 at 20:32 Andrew Robinson <arobinson18@xxxxxxxxxx> wrote:
Dev-Cpp is just a compiler, so any program written in standard C or C++ will
work with it. The Allegro5 devpak is written for C++, which is not a problem,
but the Allegro project website says that the Allegro5 libraries are written
in C, not C++, so whoever is writing these Allegro5 devpaks, is only providing
a C++ version. Sounds like someone needs to make an Allegro5 devpak that is
written for C. Is there anyone out there in the community that is willing to
do that, or is the Allegro community dying?

Using MSYS2 to install a Linux environment in Windows so you can use a Linux
compiler is a joke. This needs to be done right and using Dev-Cpp was the
right way to do it. If your best advice is "you are on your own", then Allegro
is a dead project or it needs to be.

On 5/8/2016 at 11:38 AM, SiegeLord <siegelordex@xxxxxxxxxx> wrote:
>Allegro 5 isn't compatible in any way with Allegro 4, which is why there
>are several Devpak versions of it (AGUP in particular is only for
>Allegro 4 as you've discovered). Allegro 4 isn't at all supported these
>days, so if you opt to use it, you're a bit on your own.
>
>In general, though, DevCpp hasn't really been good for a long time now.
>I would suggest you not use it. We do have a link to the Devpacks in the
>http://liballeg.org/download.html#windows section, but hopefully the
>'Unofficial' should be enough to somewhat discourage you from using them.
>
>These days the easiest way to use Allegro (5) from Windows is via MSVC,
>by following this tutorial:
>https://wiki.allegro.cc/index.php?title=Windows,_Visual_Studio_2015_and_Nuget_Allegro_5
>
>There isn't an up-to-date tutorial for non-MSVC IDEs and compilers, but
>that is an option too (we provide binaries for MSYS2, which you could
>get working with Code::Blocks, if you wanted to).
>
>-SL
>
>On 05/08/2016 10:33 AM, Andrew Robinson wrote:
>> I just started using Dev-Cpp. I like the fact that it is portable but
>> the claim that by using the Devpaks are a good thing because even a
>> beginner could run projects from them is not true. People need to be
>> aware of this.
>> I tried the Allegro Devpaks but they don't work. For example, the
>> Allegro5 Devpak installs, but when I try also installing the Allegro GUI
>> Un-uglification Project Devpak, it refuses to install because it says I
>> don't have the Allegro Devpak installed. This is not a problem a
>> beginner could resolve. The internal naming conventions are the problem,
>> so the Allegro5 Devpak is internally named as Allegro5 instead of
>> Allegro. Bad move.
>> So then I uninstalled Allegro5 and installed the Allegro4.4.2 Devpak.
>> Okay, now the Allegro GUI Un-uglification Project Devpak installs, so
>> now onto the next problem. Allegro4.4.2 won't compile. Why not? Well I
>> want to compile a 32-bit program but the compile log says Allegro4.4.2
>> isn't compatible with 64-bit. Shit! That's when I realize that none of
>> the Devpaks tell me if they are 32-bit or 64-bit, I would have to try
>> each one, one at a time, and see if any of the them is a 32-bit version.
>> But wait! There is more! Before doing that, I tried compiling my project
>> as a 64-bit project anyways, and guess what? It doesn't work! Why not?
>> At first I couldn't tell, but then I noticed that the compiler was
>> looking for a file named "lallegro-4.2.2-monolith-mt" but in the lib
>> directory installed by the Devpak, the file is named
>> "liballegro-4.2.2-monolith-mt". Do you think a beginner is going to
>> solve that problem?
>> All this tells me is that the Devpaks are a joke. They aren't documented
>> very well. They need a comment section so people can give feedback on
>> whether they really work, or whether they use the proper naming
>> convention (i.e. -- "lib" instead of "l"), and so on. Because there is
>> no feedback or control, I can't trust Devpaks. People can put anything
>> they want in it, which just makes programming all the more difficult
>> when you run into problems. And good luck if you want to upgrade your
>> project from version 4.2.2 to 4.2.3, since the libs and headers could
>> have anything in them, meaning you have no guarantee of compatibility.
>> I hope the allegro.cc instructions for compiling the Allegro
>> binaries/libraries for yourself is complete and works, because if they
>> aren't, I'm not going to be using Allegro.
>> You need to recommend that Devpaks are not to be trusted and you should
>> not use them ... unless you know how to fix the numerous problems that
>> Devpaks have presented.
>>
>>
>> _______________________________________________
>> Allegro-developers mailing list
>> Allegro-developers@xxxxxxxxxx
>> https://mail.gna.org/listinfo/allegro-developers
>>


_______________________________________________
Allegro-developers mailing list
Allegro-developers@xxxxxxxxxx
https://mail.gna.org/listinfo/allegro-developers


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/