On 21.01.2011 02:06, Greg Ercolano wrote: > > Unfortunately SVN is down; I need to update to the latest with the > FL_LIBRARY > stuff I think, bc getting a lot of errors from the DLL build that seem > to be > about Fl_x.cxx (etc) which it shouldn't be looking at under WIN32.
That's probably because you /have/ the new FL_LIBRARY stuff, but the VC6 IDE hasn't been updated (but you seem to have found this yourself). > I seem to be able to build OK with both Release and Debug for everything > except the dll stuff. Hmm, then you must be using a version before 8288? Wondering... > I think part of the problem is the debug build puts the resulting dll > in the > test directory, while a release build puts it in Releases. Me too. > Probably both should put the fll in Debug/Releases, and have a > post-build > step that copies them to the test dir, as I think many of the test apps > won't work without the dll, IIRC. Eventually I could build /everything/ except the dll's, thus I conclude that all the test programs are linked statically. >> FYI: We looked for a way not to expose FLTK's internals (class Fl_X >> etc.) and found that some FLTK projects define FL_LIBRARY when compiling >> the library files (together with FL_DLL), and so we decided to use this. >> Unfortunately FL_LIBRARY had only been defined in the DLL projects, but >> now we do also need it in the 'fltk' project, as well as all other fltk >> library project files (fltk_images, fltk_gl, fltk_forms). > > I see; this might explain some of the errs I'm getting from > building the fltkdll et al. > > Waiting for SVN to come back so I can update to current. It's up again, but it's now more that 8 hours since your mail. Mike mailed to me that they (or their provider) had a power problem, and that he needed to reset something (more than 4 hours ago, when I was sleeping ;-)). > I've never really used the dll stuff before or learned > our use of it. (ie. the dll export stuff). I've always > done everything static to avoid dll hell. Me too, and MS are making it much more difficult than others (as usual, I'd say ;-)). >>> OK, so in the case of the VS6 files, there are actually raw CL commands, >>> so it looks like I should change: >>> >>> - # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" .. >>> + # ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "FL_LIBRARY" /D "NDEBUG" >>> .. >>> ^^^^^^^^^^^^^^^ >> >> Sorry again, you're right, I think that I edited the files *after* >> conversion into the VisualC2008 format. What you wrote above is correct. > > I've also been able to change these things from the VS6 GUI as well. Yes, but this is easier with an editor, IMHO. >> Okay, but if you have VC6 installed, you ought to be able to open the >> project and look at the dependencies. > > In VS6 there's a Projects -> Dependencies which shows which other > projects > a project is dependent on. It has a check list with a list of the > other projects; all are disabled of course because fltk isn't dependent > on any of them. ... see below... > But no right click menu for e.g. the 'fltk' project that lets one view > the project dependencies. I guess they didn't have that in 1998, which > is what Help->About tells me is the release of this compiler. > >> context menu. Then you can check (or uncheck) each dependency. You can >> check the resulting "Build Order" with the corresponding tab. When >> you're done with one project, you can select another project /in/ the >> dependencies window. That's nice and efficient. > > You're way off in the future I think ;) Oh, no! You're way off in the past ;-) >>> Did the 'Debug' build of the DLL's work, but the 'Release' didn't? >>> I think that's what Brian was mentioning (in the STR). >> >> In my case both didn't work, but I used the old VC6 project w/o Brian's >> changes. I'd like to try it now, but I can't access the file right now, >> as you know. :-( > > Oh, I have a copy on my machine here. I've put a copy here: > http://seriss.com/people/erco/fltk/tmp/visualc++v6_build_files.zip Too late, I got it before I went to bed, but couldn't test anymore. And I won't get the time to do it until tomorrow. I hope that you will have some updates until then ? >> Okay, since I can't access Brian's files, let's talk about dependencies. >> Probably you know all this, but that's what I did: >> >> Notation is: >> project: depends on... (-- means no dependencies) >> >> Listing is in build order from my converted VC6 project, w/o the dll >> projects: >> >> fltk_zlib: -- >> fltk_png: fltk_zlib >> fltk_jpeg: -- >> fltk: fltk_jpeg, fltk_png >> fltk_forms: fltk >> fltk_images: fltk, fltk_jpeg, fltk_png >> fltk_gl: fltk >> Fluid: fltk, fltk_forms, fltk_images > > Good to know. > > But hmm, why is fltk dependent on fltk_jpeg and fltk_png? > I'd figure only fltk_images would be dependent on all that. Yeah, that's what I first thought, too. But the base Fl_PNG_Image etc. classes are in 'fltk' - only Fl_Shared_Image etc. are in fltk_images. Only if you disable zlib, jpeg, and png, then you get a 'fltk' lib w/o image support, and you don't need fltk_images at all. > In the VS6 files, fltk is not dependent on anything, which is what > I'd expect, but maybe there's reasons this is no longer true. I don't know how it was in fltk 1.0, but in 1.1 it was probably always (as long as I use it, and I believe this is since 1.1.0) as it is now. The problem is that VC6 didn't get it, and you could define what you wanted. In VC2008 I could not /remove/ this dependency or another one (I don't remember) because it told me that it was system-generated (or so). I also couldn't set another dependency, because it told me that this would be a circular dep. I had to remove another (wrong) dep. to make it work. >> I don't know whether Fluid's dependencies are all "true", but they make >> sure that all the libs are built before Fluid. > > Yes, that makes sense. > And I'm sure several test programs are dependent on fluid.. > or at least should be. Good point. All worked for me, but I don't know if this was magic :) or explicit dependencies. > Think an improper dependency arrangement > was one of the reasons the new express compiler would often fail, > because during parallel builds, it would get ahead of itself > due to missing dependencies. For a time 'serializing' the build > would fix that, where I guess the 'build order' helped keep that > working smoothly in absence of dependencies. The 'build order' is derived from the dependencies, you can't change it directly. I think that wrong dependencies made it work if you started 'Build Solution' twice or more. >> The *dll projects depend on their corresponding dll versions. All other >> test programs depend on the libs, as it should be obvious. > > I think some test programs used to build wanting DLLs. > Some did, some didn't.. never knew what was up with that, > but I remember for a time we had to manually copy the dll from > the release dir to the test dir for test apps to run. Now it's > done automatically, but I think not consistently. (see above > regarding Debug builds wanting to put the dll in the test dir, > but the Release was putting it in Release) Yes, that's what I saw too, but I don't know the correct solution. The test dir seems definitely wrong though. > Sure is quiet in here; I think we're the only ones talking > cause we're the only ones using the /etc/hosts workaround.. > . ... and then I went to bed and left you alone ;-) But now everything should be online again. I hope that we don't suffer from another day to propagate the full DNS info around the world again. Albrecht _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
