Greg Ercolano wrote:
> I've posted "visualc-tree-table-fnfc.tar.gz" in STR# 2298:
> http://www.fltk.org/str.php?L2298
[...]
> These files are /hand edits/, and although I'm fairly confident
> these edits are correct, would be good to get some external verifications.
>
> Albrecht or Matt: If you have a second, feel free to xdiff the above files
> in the tar file against svn current to verify my changes look OK.
Good work, looks good for me so far.
I looked at the files with fldiff (as a FLTK user I'm using fldiff,
of course ;-) ), and everything looks fine, maybe with one small
exception that I don't understand:
In file fltkdll.dsp there are sections that look like dependencies,
and the suspicious thing is that some of the "names" (?) are used
more than once. I don't know if this has effects on the build though.
There is:
SOURCE=..\..\src\Fl_Table.cxx
DEP_CPP_FL_TR=\
SOURCE=..\..\src\Fl_Table_Row.cxx
DEP_CPP_FL_TR=\
SOURCE=..\..\src\Fl_Tree.cxx
DEP_CPP_FL_TR=\
There are other similar cases that seem to imply that the "names"
should be unique, e.g.
SOURCE=..\..\src\Fl_Text_Buffer.cxx
DEP_CPP_FL_TE=\
SOURCE=..\..\src\Fl_Text_Display.cxx
DEP_CPP_FL_TEX=\
SOURCE=..\..\src\Fl_Text_Editor.cxx
DEP_CPP_FL_TEXT=\
It looks as if there is always one more letter to make the names
unique. Maybe ...
To verify the new project files I did:
$ for f in native-filechooser table tree ; do echo "--- $f ---" \
&& sed -e "s/hello/$f/g" < ../ide/visualc/hello.dsp | u2d > $f.dsp \
&& diff -u $f.dsp ide/visualc/$f.dsp; done
--- native-filechooser ---
--- table ---
--- tree ---
That is, there are no diffs. Looks like an easy way to create a .dsp
file for a new test program ;-) . I had to use u2d though, so that
the created file had cr/lf endings like your files and the original
project files have.
WRT svn properties: most of the files obviously have "binary"
attributes ("svn:mime-type application/octet-stream"), but some
have "svn:eol-style CRLF". I'm not sure which one is better, but
I think that we could set "svn:eol-style CRLF", since all files
are text files, as you wrote before.
...
Okay, I just tested it with a local svn repository: as I assumed,
we can see differences if the file has text format ("svn:eol-style
CRLF"), but there's no diff, if the file is binary (and, IIRC,
internally (in the repository) the binary file is saved completely
and not as a diff. It seems to work though, and since some of the
files *are* already checked in as text, I think that we could try
to make them all text with CRLF. Maybe...
BTW.: While you're at it: I looked at the project files today,
because I wanted to find out what we have, and why someone
recently wrote that there are cairo dependencies, and because
I wanted check the WIN32/_WIN32 problem. I found this:
ide/visualc is an older version ("6.00") of MS VS, and the
contents are not as much up-to-date as the other project files
in:
ide/vc2005 is MS VS version "8,00" (don't know why there's a
comma and not a decimal point - maybe someone with a German
or French version wrote them).
In ide/vc2005 there are obviously 4 project configurations:
Name="Debug|Win32"
Name="Release|Win32"
Name="Debug Cairo|Win32"
Name="Release Cairo|Win32"
I couldn't find out which one is the default configuration,
although there's something like ".ActiveCfg =" that seems
to point to "Release Cairo|Win32" or "Debug Cairo|Win32"
in some cases...
I think that Fabien added the Cairo configurations, and he
wrote something about it in README.cairo:
'... vc2005 build files have 2 new build modes "Release Cairo"
and "Debug Cairo".'
Another difference is: in these project settings we have
'PreprocessorDefinitions="_CRT_SECURE_NO_DEPRECATE;WIN32;...'
which means that we should not get the warnings about
snprintf when compiling.
Questions: Greg, can you open the project files in ide/vc2005,
and if yes, what is the default configuration, and what
happens if you compile and build with them? I assume that
your previous tests all were with ide/visualc, right?
These files look much more complicated though, because they
are in XML format and make intensive use of GUID's. Maybe
not as easy to hand-edit.
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
