Hi, no problem, I will just wait for the 1.3.3 final to be released. Just before you set it as final, I might be able to test it again on Windows and Linux, if it could help you.
Regarding the dependencies, I hope SDL (1.2.x and maybe 1.3.x in the future) will still be supported, as an alternative to the framebuffer. Having a portable GUI that can run on top of SDL and/or OpenGL is surely of great help. Best regards, Olivier. Julien Nadeau a écrit : > Hi. > > On Sat, Oct 25, 2008 at 02:54:37PM +0200, Olivier Boudeville wrote: > >> Hi, >> >> here is some feedback regarding the build of core and gui of 1.3.3-rc2 >> with Visual C++ 2008. Long story short, this finally succeeded, but >> after some efforts and changes. >> >> I selected the flavour I was interested in, >> vs2005-windows-i386-nothreads.zip (for the config files only, as I am >> using custom-made .sln/.vcproj files). >> >> - core_init.h includes agar/begin.h whereas begin.h is at the root of >> the extracted archive. Thus a fix is including begin.h directly; same >> thing for close.h. However lots of includes are relative to an "agar" >> directory, thus I temporarily renamed the "agar-1.3.3-rc2" base >> directory to "agar" and added its parent directory in the include path... >> I did not understand why an "agar" directory was mentioned as such (the >> library is not expected to be built against its already installed >> headers, is it?) >> >> - config/have_dlopen.h, config/have_dlfcn_h.h, etc. were needed by >> core/dso.c but were not available in the vs2005 archives (I removed the >> #include for the test) >> >> - still in dso.c, line 170, there is most probably a bug (assignment >> written as a test) >> > > These have been fixed in SVN (see below). > > >> - there is a warning in core/prop.c, lines 47 and 64, due to different >> const qualifiers >> > > It is safe to ignore those. > > >> With these changes a non-empty .dll and .lib could be produced for >> ag_core. However some symbols were still lacking, at least the ones for >> all the exported variables (ex: agConfig), whereas the functions were >> available. This was due to the use of the Agar DECLSPEC define, that >> should, in my opinion, be improved, as explained later in this mail. >> > > That was fixed in SVN. The header files as used for compilation are now > preprocessed into includes/, such that DECLSPEC (expanding to dllimport > or dllexport) is added to all declarations within __BEGIN_DECLS blocks. > > >> Why are there includes of gui headers from core files ? (ex: >> core/config.c including gui/view.h, same thing for core/rcs.c). Isn't >> gui meant to depend on core, and not the opposite? Moreover these >> includes can be removed without breaking the build of core! Finally I >> found other includes of gui from core that were actually necessary. Thus >> core and gui are mutually dependent, as I understand now. >> > > The dependencies in core/config.c were bogus and were removed in SVN. > The core library should not depend on gui in any way. > > >> Why AG_ProcessEvent, that depends on SDL, ends up declared in core >> (core/event.h) whereas defined in gui (gui/view.c) ? Same thing about >> AG_WriteColor (core/load_color.c). Maybe a nicer and cleaner separation >> could be at least to have only gui depending on SDL? >> > > Another oversight on my part. I've just moved the declarations to the > proper headers. Currently, core depends on SDL only for SDL_Delay() used > in the timeout system, and AG_Quit() which uses SDL_PushEvent(). We will > have those references removed in the next release. > > The plan, within the next few releases, is to remove the SDL dependency > from gui as well (reimplementing the FB rendering mode as a module). > > >> Another concern is gui using its own extern declarations of core symbols >> instead of including the core headers: when building gui, I think that >> the DECLSPEC define should resolve into dllimport for core symbols and >> dllexport for gui symbols. The same symbol cannot be used for both, >> which is the explanation for the unresolved externals for agConfig and >> al that I already mentioned. >> > > Yes, that was addressed in the recent includes/ changes. On the relevant > platforms, DECLSPEC now expands to dllimport or dllexport (or the GCC > visibility attribute under GCC4), depending on whether the library > itself is being compiled or used externally. > > >> My suggested fix would be to use respectively AGAR_CORE_DLL and >> AGAR_GUI_DLL defines instead of DECLSPEC, which would be defined on a >> per-library basis. >> > > We went with library-specific "begin.h" and "close.h" headers. As a > bonus, it allows things like the __BEGIN_DECLS definition itself or > the FOO_ATTRIBUTE macros to be defined/undone in a clean way without > relying on other includes. > > >> Finally, in core/snprintf.h and other core headers, AG_Snprintf, >> AG_Vsnprintf and AG_Vasprintf had no extern nor DLL export declaration, >> whereas they are widely used by gui. >> > > Ah! I was considering those to be internals but I realize now that they > are referenced by many static __inline__ routines. A fix will be committed > shortly. > > >> I applied all these suggestions to core and gui and was able to compile >> and link them flawlessly. At last gui could resolve all the symbols it >> needed from core, thus I believe the build is ok now. >> >> Julien, I can send you off-list a zip archive containing the modified >> sources and project files, and the resulting .LIB/.DLL, for core and for >> gui. >> > > Thanks but your e-mail explained the issues clearly enough, and the > project files we use happen to be generated. > > Ps. Thank you so much for your efforts. I apologize for not having kept > you informed on the changes in SVN, that might have avoided some duplicate > work. If you would like to receive commit notices, see "agar-commits", > under http://libagar.org/lists.html. > > > > _______________________________________________ Agar mailing list [email protected] http://libagar.org/lists.html
