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.
I seem to be able to build OK with both Release and Debug for everything
except the dll stuff.
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.
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.
>>> fltk_jpeg.dsp <-- JPEG
>>> fltk_png.dsp <-- PNG
>>> fltk_zlib.dsp <-- ZLIB
>> Should we /not/ do those?
>
> No, we shouldn't you're right. I was probably transposing(?) it from
> VC2008, where the projects have different names (jpeg, libpng, and
> zlib). Sorry for the confusion.
OK, got it.
> 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.
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.
> The bundled libs (jpeg, png, zlib) don't need it since they don't use
> FLTK's internals.
>
> The "executable" projects (fluid and test/*) must not define it, because
> that would generate wrong bindings for the dll's (see FL_EXPORT in
> FL/Fl_Export.H).
I see.
>> 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.
> 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.
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 ;)
>> 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
> 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.
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 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. 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 *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)
Sure is quiet in here; I think we're the only ones talking
cause we're the only ones using the /etc/hosts workaround..
.
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
