Enet in Visual Studio?

[Josh]

I am using Enet to set up a Lua debugger. I compiled the Enet library from the MSVC project in the download. I placed the resulting enet.lib file in "Microsoft Visual Studio 9.0\VC\lib". In my project properties, in "Configuration Properties > Linker > Input > Additional Dependencies" I added "enet.lib". When I use any enet functions or classes the compiler doesn't recognize them. What else do I have to do to use it?

[Drew_Benton]

The general rule of thumb is to never copy any user/3rd party header files/libs into the base compiler paths.

 

Instead, you just want to place it (the complete enet package) in a stable path that won't be changing, for example, "C:\dev". Once you have it in a stable path, you can:

1. Click Tools->Options

2. Projects and Settings->VC++ Directories.

3. Choose "Library files" and add the directory to the end of the list that contains the library files.

4. Choose "Include files" and add the directory to the end of the list that contains the base paths to the header files.

 

Now, you can #include<enet.h> and it will search the registered directories first and find it. Likewise, when the linker goes to search its paths for the library you added in the Additional Dependencies, it'll go there first. See: what is the difference between #include <filename> and #include “filename” as well.

 

This method is for global libraries though, things you set once and want to reuse for many projects. You maintain only 1 version of the library.

 

If you only want to setup the current project only, what you do instead is:

1. Click Project->Properties

2. Choose Configuration Properties->C/C++

3. Click the right most "..." button inside the "Additional Include Directories" field.

4. Add the directory to the end of the list that contains the base path for the header files

5. Choose Configuration Properties->Linker

6. Click the right most "..." button inside the "Additional Library Directories" field.

7. Add the directory to the end of the list that contains the library files.

8. Repeat for each "Configuration" (Debug/Release for example)

 

Now, only the current project is setup to look for the library from a common path.

 

IMPORTANT NOTE: Depending on how the API is setup determines which header folder you add. For example, it is advised to use the 'include' folder as the base header path (#include <enet/enet.h>) rather than using the 'enet' folder as the base path (#include<enet>). The reason why you usually take the first approach is to avoid header file name conflicts.

 

The global approach is good for existing libraries that are common dependencies among many projects. The local approach is good for when you have different versions of the same library that you need to use in different projects. For example, there are many versions of ZLIB. If you need to use specific versions across different projects, then you have to set the paths for each library individually. If you were only using one version of ZLIB for all projects, then you can just setup the global paths instead.

 

One last important note. Maintaining dependencies can be very tricky if you are not careful. For example, let's say you use the global approach. You migrate computers in the future and forget to save the the exact version you were using. Or, you send the code to someone who does not have the same dependency in the path you did. All sorts of coding headaches can arise as a result of this. I myself would rather keep all dependencies in a workspace folder for the projects I am using it with, so when I backup the project or send it to someone, everything they need is right there.

 

Also, if you go and change anything in the global path, you will need to recompile all projects that depended on it and retest them to make sure they do not break. I've seen a lot of projects get ruined from simple things like this and I've made the mistake one too many times! Setting up a personal source code repository can help with the matter as well.

[Rick]

Like Drew said (but more in a 1 liner) the idea is to point your VS to the 3rd parties include and library folders.

[Krankzinnig]

Check that your are using the namespace enet is wrapped in and place all of the enet include files in Microsoft Visual Studio 9.0\VC\include

 

Keep dropping your libs in there you wont need to set up your directories of course because MSVC already looks for these folders automatically. Also you don't have to update your linker for each configuration setting, you can just choose "All Configurations" if your Debug and Release settings use the same libs.

[Josh]

Got it sorted, thanks.

[Krankzinnig]

You should compile LE3 in Code::Blocks or ill riot.

[Rick]

VS or I'll riot. Oh man what's he going to do now

[Josh]

The general rule of thumb is to never copy any user/3rd party header files/libs into the base compiler paths.

Why? It's so difficult to keep all those additional directories straight.

 

Now I am getting all these linker errors:

1>Linking...

1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

1>enet.lib(host.obj) : error LNK2019: unresolved external symbol __imp__htonl@4 referenced in function _enet_host_connect

1>enet.lib(peer.obj) : error LNK2001: unresolved external symbol __imp__htonl@4

1>enet.lib(packet.obj) : error LNK2001: unresolved external symbol __imp__htonl@4

1>enet.lib(protocol.obj) : error LNK2001: unresolved external symbol __imp__htonl@4

1>enet.lib(host.obj) : error LNK2019: unresolved external symbol __imp__htons@4 referenced in function _enet_host_connect

1>enet.lib(win32.obj) : error LNK2001: unresolved external symbol __imp__htons@4

1>enet.lib(peer.obj) : error LNK2001: unresolved external symbol __imp__htons@4

1>enet.lib(protocol.obj) : error LNK2001: unresolved external symbol __imp__htons@4

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__WSACleanup@0 referenced in function _enet_initialize

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__WSAStartup@8 referenced in function _enet_initialize

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__inet_addr@4 referenced in function _enet_address_set_host

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__gethostbyname@4 referenced in function _enet_address_set_host

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__inet_ntoa@4 referenced in function _enet_address_get_host_ip

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__gethostbyaddr@12 referenced in function _enet_address_get_host

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__bind@12 referenced in function _enet_socket_bind

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__listen@8 referenced in function _enet_socket_listen

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__socket@12 referenced in function _enet_socket_create

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__setsockopt@20 referenced in function _enet_socket_set_option

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__ioctlsocket@12 referenced in function _enet_socket_set_option

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__connect@12 referenced in function _enet_socket_connect

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__ntohs@4 referenced in function _enet_socket_accept

1>enet.lib(peer.obj) : error LNK2001: unresolved external symbol __imp__ntohs@4

1>enet.lib(protocol.obj) : error LNK2001: unresolved external symbol __imp__ntohs@4

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__accept@12 referenced in function _enet_socket_accept

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__closesocket@4 referenced in function _enet_socket_destroy

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__WSAGetLastError@0 referenced in function _enet_socket_send

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__WSASendTo@36 referenced in function _enet_socket_send

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__WSARecvFrom@36 referenced in function _enet_socket_receive

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol __imp__select@20 referenced in function _enet_socketset_select

1>enet.lib(win32.obj) : error LNK2019: unresolved external symbol ___WSAFDIsSet@8 referenced in function _enet_socket_wait

1>enet.lib(peer.obj) : error LNK2019: unresolved external symbol __imp__ntohl@4 referenced in function _enet_peer_send

1>enet.lib(protocol.obj) : error LNK2001: unresolved external symbol __imp__ntohl@4

[Josh]

Ah, I needed these:

ws2_32.lib

winmm.lib

[Josh]

Now this is interesting. Why would this not detect the debugger connecting? An almost identical BlitzMax program works fine:

                        if (enet_initialize()!=0)
                       {
                               Print("Failed to initialize enet.");
                       }
                       else
                       {
                               ENetAddress address;
                               ENetEvent enetevent;
                               address.host = ENET_HOST_ANY;
                               address.port = 7776;
                               InterpreterDebugHost = enet_host_create(&address,64,0,0);
                               if (InterpreterDebugHost==NULL)
                               {
                                       Print("Failed to create host on port "+String(address.port));
                               }
                               else
                               {
                                       Print("Checking for events loop...");
                                       bool exitloop = false;
                                       int time = Millisecs();
                                       while (true)
                                       {
                                               int result = enet_host_service(InterpreterDebugHost,&enetevent,0);
                                               if (result>0)
                                               {
                                                       switch (enetevent.type)
                                                       {
                                                       case ENET_EVENT_TYPE_CONNECT:
                                                               Print("Connect");
                                                               exitloop=true;
                                                               break;
                                                       case ENET_EVENT_TYPE_DISCONNECT:
                                                               Print("Disconnect");
                                                               break;
                                                       case ENET_EVENT_TYPE_RECEIVE:
                                                               Print("Receive");
                                                               break;
                                                       case ENET_EVENT_TYPE_NONE:
                                                               Print("No event");
                                                               break;
                                                       }
                                               }
                                               else
                                               {
                                                       if (result<0) Print("enet_host_service failed.");
                                               }
                                               if (Millisecs()-time>10000) exitloop = true;
                                               if (exitloop) break;
                                       }
                                       Print("Done with events loop");
                               }
                       }
               }

[Canardia]

I agree with Krankzinnig, you do yourself and others a big favor by using Code:.Blocks, because it detects and warns automatically about a lot of problems in bad C++ code. VS just accepts all ****, and suggests things which you should not use, so it teaches you bad programming.

[Krankzinnig]

Eh not to mention using Code::Blocks eliminates the runtime package needed to run MSVC applications. Don't give me that "everyone has it anyway" because they don't and its terrible. Compile in MSVC, then the same exact application in MinGW with memory/speed optimization checked and you can see the difference. There is no need for MSVC, Code::Blocks has auto complete, auto save, and etc features in a considerably smaller package.

[Pixel Perfect]

VS just accepts all ****, and suggests things which you should not use, so it teaches you bad programming.

lol yet another pointless 'lets bash MS' statement from the king of pointless statements! It doesn't teach you to be a bad programmer at all. Who's in charge of the code ... you or the IDE If you are a bad programmer then you'll write bad code ... period

[Krankzinnig]

Well, the only thing is that there are standards when writing C++ code. MSVC invents its own standards. Although its not "bad", its not the most efficient way by any means. Like I was saying, Code::Blocks is so clean and neat, really boosts my productivity. Its totally worth checking out since its free and much smaller for your end user. GCC gives more clear error imo too.

[Canardia]

There's no point arguing with MS fanatics, the people who know the benefits of open source and cross-platform are so much further in evolution, that it would be pointless even to try to explain the benefits to the MS fanatics

[Pixel Perfect]

I'm no MS fanatic Lumooja, but nither am I so deluded as to believe that everything MS does is bad and part of some evil plot! If you're an example of what we are all to evolve into Lumooja then god help us all, the human race is doomed

[Krankzinnig]

Its really not about who made it or what licensing it uses. The point is efficiency, GCC via MinGW has more then proven its superiority over the Microsoft C compiler. Its because it can be updated much faster because that's all they focus on. MS has a lot of products so it takes a while for all of them to catch up. I use a very well blended tool set.

 

The point is, don't argue about it, have an open mind and actually try it yourself. There are really cool build properties that makes for insanely small clients. I just hate my end user to require dependencies. The more run-times, dll files and etc the more headaches. Also isn't LE 3 cross platform? It would be best to using a IDE and compiler suite that actually runs on multiple operating systems.

 

Myself, I am using MSVC to write my games, then final build before I release is all mingw.

 

 

 

I think people use MSVC so they don't have to give up their precious pragma comments ;P

[Josh]

Don't hijack threads.