-DDEBUG breaking compilation?

[Kevin Ingwersen]

Hey. I am improving the build schemes for my build system. When I compile FLTK now, I get some weird errors. Is this intended or alike?

Ingwie@Ingwies-Air ~/Work/deskshell $ build --view=make --enable-debug
-- Debug enabled.
g++ -g -DDEBUG -fPIC -fno-common -Wno-pointer-sign -Wno-deprecated-declarations -Wno-c++11-narrowing -Ilibuv/include -Iuvpp -Ihttp-parser -Ic-ares/include -Isqlite3 -ITrololo -Iphp/main -Iphp/TSRM -Iphp/Zend -Iphp-ext/PHP-CPP -std=c++11 -Iembed2-sapi/src/ -DDARWIN -Ittvfs/ttvfs -Ittvfs/ttvfs_zip -Ilibcanister -Ilibucl/include -IFLTK -IFLTK/png -DFL_LIBRARY -c FLTK/src/Fl_File_Icon2.cxx -o FLTK/src/Fl_File_Icon2.cxx.o
FLTK/src/Fl_File_Icon2.cxx:573:33: error: use of undeclared identifier 'xpm'
printf("Icon File \"%s\":\n", xpm);
^
FLTK/src/Fl_File_Icon2.cxx:574:8: error: use of undeclared identifier 'i'
for (i = 0; i < num_data_; i ++)
^
FLTK/src/Fl_File_Icon2.cxx:574:15: error: use of undeclared identifier 'i'
for (i = 0; i < num_data_; i ++)
^
FLTK/src/Fl_File_Icon2.cxx:574:30: error: use of undeclared identifier 'i'
for (i = 0; i < num_data_; i ++)
^
FLTK/src/Fl_File_Icon2.cxx:575:31: error: use of undeclared identifier 'i'
printf(" %d,\n", data_[i]);
^
5 errors generated.
Command exited with errorcode 1.


Without -DDEBUG, it works.

Kind regards, Ingwie

[MacArthur, Ian (Selex ES, UK)]

Hmm, no idea.

Ingwie, you may be the only person who's actually built with DEBUG enabled in the last decade, I suspect!

Wonder what happened to Fl_File_Icon2.cxx, do you have local mods that are triggering this, or does the "stock" one do it too, do you know?




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Kevin Ingwersen]

I am using the svn stock…to be exact, the current version mirrored to my github fork ( https://github.com/IngwiePhoenix/FLTK.git ).

After looking around, I can tell people havent used -DDEBUG in a while =p

A small code cleanup will solve this. Actualy, I could simply do it myself, however, I dont know how I would then issue my changes as a „pull request“…i never learned svn o-o

[MacArthur, Ian (Selex ES, UK)]

> >> Without -DDEBUG, it works.
> >
> > Hmm, no idea.
> >
> > Ingwie, you may be the only person who's actually built with DEBUG
> enabled in the last decade, I suspect!
> >
> > Wonder what happened to Fl_File_Icon2.cxx, do you have local mods
> that are triggering this, or does the "stock" one do it too, do you
> know?
> >
>

> I am using the svn stock...to be exact, the current version mirrored to

> my github fork ( https://github.com/IngwiePhoenix/FLTK.git ).
>
> After looking around, I can tell people havent used -DDEBUG in a while
> =p
>
> A small code cleanup will solve this. Actualy, I could simply do it
> myself, however, I dont know how I would then issue my changes as a

> "pull request"...i never learned svn o-o


Make the change, then generate a patch that contains just the change, and post the patch as an STR for one of the devs to pick up and commit.

You know how to generate a patch file, I guess?

("svn diff", or "git --patch" I think, or the traditional "diff -Naur oldir newdir" would be my take on this, though I'm far from certain about the git options!)

[Greg Ercolano]

On 04/28/14 23:58, Kevin Ingwersen wrote:
> Hey. I am improving the build schemes for my build system. When I compile FLTK now, I get some weird errors. Is this intended or alike?
>
> Ingwie@Ingwies-Air ~/Work/deskshell $ build --view=make --enable-debug
> -- Debug enabled.
>

> g++ -g -DDEBUG [..] -o FLTK/src/Fl_File_Icon2.cxx.o

> FLTK/src/Fl_File_Icon2.cxx:573:33: error: use of undeclared identifier 'xpm'
> printf("Icon File \"%s\":\n", xpm);

-DDEBUG is not something out build system sets when building a debug
version of FLTK is built (e.g. "./configure --enable-debug'),
so your build system for building FLTK probably shouldn't either.

For instance if I build the FLTK source with --enable-debug:

./configure --enable-debug ; sed -ie 's/^.SILENT/#.SILENT/' makeinclude ; make

..which on my system shows the build line for Fl_File_Icont2.cxx as being:

[..snip..]
g++ -I.. -I../png -I../jpeg -g -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -DFL_LIBRARY -c Fl_File_Icon2.cxx -o Fl_File_Icon2.o
[..snip..]

..note no -DDEBUG is present.

If you're going to build FLTK with custom makefiles, then you should
probably routinely compare the compile lines of your builds to the
regular FLTK './configure; make' output (with .SILENT commented out
in makeinclude, which is what the 'sed' command does in the above)
to make sure your build system and FLTK's are in sync.

I forgot why you're using your own build system to build the FLTK lib
instead of letting FLTK's configure + make build it.

Adding foreign compiler flags like -Dxxx and -std=c++11 can be done
via environment variables like CXXFLAGS:

( export CXXFLAGS="-Wno-c++11-narrowing -Ilibuv/include -Iuvpp [..etc..]"; ./configure --enable-debug; make )

Also, I see you're setting some -I and -D flags that are foreign to FLTK's
code..

Flags like "-Isqlite3", "-ITrololo", etc. seems like it's just asking for
trouble with macro and include file conflicts with fltk's internal macros/includes
if not now, further down the road..

For instance, non-public includes internal to FLTK like those in config.h
could conflict with those other include files that likely have similar
variables (e.g. HAVE_XXX)

Why are flags like -Isqlite3 needed for building FLTK?

Unless you've hacked FLTK source to use e.g. sqllite3, in which case
I'd suggest supplying those flags only to the hacked FLTK files,
not all files to avoid conflicts.

[Kevin Ingwersen]

Am 29.04.2014 um 18:26 schrieb Greg Ercolano <erco_...@seriss.com>:

> -DDEBUG is not something out build system sets when building a debug
> version of FLTK is built (e.g. "./configure --enable-debug'),
> so your build system for building FLTK probably shouldn't either.
>
> For instance if I build the FLTK source with --enable-debug:
>
> ./configure --enable-debug ; sed -ie 's/^.SILENT/#.SILENT/' makeinclude ; make
>
> ..which on my system shows the build line for Fl_File_Icont2.cxx as being:
>
> [..snip..]
> g++ -I.. -I../png -I../jpeg -g -Wno-deprecated-declarations -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -DFL_LIBRARY -c Fl_File_Icon2.cxx -o Fl_File_Icon2.o
> [..snip..]
>
> ..note no -DDEBUG is present.

Ahh…I am no Makefile/Autoconf junky :). I was just guessing it rather blindly. But surprisingly, using the flag actually -did- something o.o

> If you're going to build FLTK with custom makefiles, then you should
> probably routinely compare the compile lines of your builds to the
> regular FLTK './configure; make' output (with .SILENT commented out
> in makeinclude, which is what the 'sed' command does in the above)
> to make sure your build system and FLTK's are in sync.

Yeah, I will strip the -DDEBUG. But it might be worth a research why FLTK’s source actually reacts to it.

>
> I forgot why you're using your own build system to build the FLTK lib
> instead of letting FLTK's configure + make build it.

https://github.com/Deskshell-Core/PhoenixEngine
It uses IceTea ( http://github.com/IngwiePhoenix/IceTea ) to build all projects - see all files within .IceTea/ - and cDetect ( https://github.com/IngwiePhoenix/cDetect ) to handle autoconf like configuration.
Goal: To be cross-platform. I do not want to rely on CMake or other „restricted“ tools. I choose to use Xagasoft’s Build, which IceTea is a fork of, due to the simple but complete syntax. Took me a while to do this decision, but that way I can control many things.
But to be honest, I have to yet clean the actual build phase some, and make sure flags arent getting messed up. I have just had problems that when I compiled one part with -std=c++11, that i couldnt link it with other code, hence I made it a global flag...

>
> Adding foreign compiler flags like -Dxxx and -std=c++11 can be done
> via environment variables like CXXFLAGS:
>
> ( export CXXFLAGS="-Wno-c++11-narrowing -Ilibuv/include -Iuvpp [..etc..]"; ./configure --enable-debug; make )
>
> Also, I see you're setting some -I and -D flags that are foreign to FLTK's
> code..
>
> Flags like "-Isqlite3", "-ITrololo", etc. seems like it's just asking for
> trouble with macro and include file conflicts with fltk's internal macros/includes
> if not now, further down the road..

FLTK doesnt even reffer to any of the includes…but i need to clean it anyway. The actual final project will need -a lot- of these includes - from fltk, but as well as sqlite3 and trololo.

>
> For instance, non-public includes internal to FLTK like those in config.h
> could conflict with those other include files that likely have similar
> variables (e.g. HAVE_XXX)
>
> Why are flags like -Isqlite3 needed for building FLTK?
>
> Unless you've hacked FLTK source to use e.g. sqllite3, in which case
> I'd suggest supplying those flags only to the hacked FLTK files,
> not all files to avoid conflicts.

I am using a clean FLTK. I was just mainly using -DDEBUG as a „global debug flag“ as most projects seemed to be happy with this - that FLTK is not, I was not expecting. However, its fast and easy to strip this out.

I can easily clean out the -DDEBUG, as IceTea supports string replacements:

CXXFLAGS = CXXFLAGS.replace("-DDEBUG","");

Although that I now know that FLTK was not ment to use -DDEBUG, I will take a look into the source…because it interests me, that if I enable the flag, that FLTK actually seems to behave differently, if only slightly.

Kind regards, Ingwie.

PS. The cDetect port of FLTK’s autoconf is to be found in Phoenix Engine -> util/fltk_configure.c

[Ian MacArthur]

On Tue Apr 29 2014 19:23:59, Kevin Ingwersen wrote:
>
>
> Although that I now know that FLTK was not ment to use -DDEBUG, I will take a look into the source...because it interests me, that if I enable the flag, that FLTK actually seems to behave differently, if only slightly.

Looks like vestigial leftovers from some testing during development or something - it doesn’t look like it would be generally useful, though.

Would be trivial to make it work again, or we can just excise it...

Changing line 574 from:

for (i = 0; i < num_data_; i ++)

to:

for (int i = 0; i < num_data_; i ++)

Would probably do the trick...

[Greg Ercolano]

Note that old compilers (SGI) will let i's scope
continue past the loop's completion. (Apparently scope wasn't
defined very well in early drafts of C++)

You can solve that I think by enclosing the loop in braces, e.g.

{

for (int i = 0; i < num_data_; i ++)

{ .. }
}

[Michael M]

known as str #3044

http://www.fltk.org/str.php?L3044+P0+S-2+C0+I0+E0+Q3044

[Michael M]

Also if you're using windows or freebsd you may find this interesting. 

http://www.fltk.org/str.php?L+QAnyCPU 

[MacArthur, Ian (Selex ES, UK)]

>
> known as str #3044
>

Yes, though as Greg points out, that may not be safe on older C++ compilers that don't constrain scope "properly" such as SGI, so we'd need some extra braces around the for loop.

That said, all this DEBUG stuff looks like dev leftovers from testing; it is not really part of FLTK.

I'd suggest that rather than trying to "fix" it we consider just stripping it out...

[MacArthur, Ian (Selex ES, UK)]

> > known as str #3044
> >
>
> Yes, though as Greg points out, that may not be safe on older C++
> compilers that don't constrain scope "properly" such as SGI, so we'd
> need some extra braces around the for loop.
>
> That said, all this DEBUG stuff looks like dev leftovers from testing;
> it is not really part of FLTK.
>
> I'd suggest that rather than trying to "fix" it we consider just
> stripping it out...

OK - despite my reservations, for now I have applied a "fix" for this.

STR #3044 closed as a result.