/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I./include -I./src/scintilla/include -I./src/scintilla/lexlib -I./src/scintilla/src -DSCI_LEXER -DLINK_LEXERS -DGTK -D__WX__ -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxscintilla.lo -MD -MP -MF .deps/wxscintilla.Tpo -c -o wxscintilla.lo `test -f 'src/wxscintilla.cpp' || echo './'`src/wxscintilla.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I./include -I./src/scintilla/include -I./src/scintilla/lexlib -I./src/scintilla/src -DSCI_LEXER -DLINK_LEXERS -DGTK -D__WX__ -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT wxscintilla.lo -MD -MP -MF .deps/wxscintilla.Tpo -c src/wxscintilla.cpp -fPIC -DPIC -o .libs/wxscintilla.o
mv -f .deps/wxscintilla.Tpo .deps/wxscintilla.Plo
make[3]: *** No rule to make target `src/scintilla/src/LexAPDL.cxx', needed by `LexAPDL.lo'. Stop.
tried make clean && make
Will a new bootstrap and configure round be needed ??
Or do I once again need to remove somewhere pch/gch 's files ?
If I see correctly, the lexers have moved to another directory, so running ./bootstrap (and ./configure is recommended).
Quote from: jens on September 15, 2010, 11:48:23 AM
If I see correctly, the lexers have moved to another directory, so running ./bootstrap (and ./configure is recommended).
True. you definitely need a clean new run.
BTW: The scintilla repo has had several major changes. One of it was the re-organisation of the folder structure. One of the advantages of the new scintilla is (btw) that it "understands"
#define's now natively. That means, if you set a
#define in the code, the appropriate sections are coloured. If you unset the
#define they are b&w... not bad. I wonder if we can use this for CC...
after doing a new ./bootstrap en ./configure round , still no luck
Making all in wxscintilla
make[3]: Entering directory `/home/ldco/CodeBlocks/trunk/src/sdk/wxscintilla'
make[3]: *** No rule to make target `src/scintilla/src/LexAPDL.cxx', needed by `LexAPDL.lo'. Stop.
???
Quote from: killerbot on September 15, 2010, 03:11:05 PM
make[3]: *** No rule to make target `src/scintilla/src/LexAPDL.cxx', needed by `LexAPDL.lo'. Stop.
Huh? If I look at:
http://svn.berlios.de/wsvn/codeblocks/trunk/src/sdk/wxscintilla/Makefile.am
then there is no
src/scintilla/src/LexAPDL.cxx, but only
src/scintilla/lexers/LexAPDL.cxx (the way/path it should be). Are you sure you did a full clean and there are no old
Makefile.am's or
Makefile's around?!
Can you compare this
Makefile.am with yours? Can you verify that the generated
Makefile is recent (dated today) after
configure?
My Makefile.am is from this morning.
Snippet :
libwxscintilla_la_SOURCES = src/PlatWX.cpp \
src/ScintillaWX.cpp \
src/wxscintilla.cpp \
src/scintilla/lexers/LexAPDL.cxx \
So that part is ok.
But I keep getting that error ... ?????
Note : make clean also fails ...
EDIT : removed the Makefile, did a new ./configure --> make --> immed. same issue
Quote from: killerbot on September 15, 2010, 03:51:47 PM
But I keep getting that error ... ?????
Right... what about a clean new checkout in a new folder? :-)
I just tried under Linux - it works here!
was already at that stage, removed all files and did again svn update, seems to move forward now ...
Quote from: killerbot on September 15, 2010, 04:12:42 PM
was already at that stage, removed all files and did again svn update, seems to move forward now ...
Yepp - I noticed such behaviour, too. I think before doing an update that modifies something of the build system (line a
Makefile.am) it's wise to make a make clean (dist clean)
before the actual update. Thus all intermediate build files of the old version are truly removed.
If you did a configure
after the svn update on a new config, then the
Makefile's are not valid to do a clean as they have been changed and the references to old object / whats-o-ever-files are lost. This usually causes build errors like in your case. :-)
probably make clean should be made more brutal: "find . -iname 'Makefile' | xargs -i {} rm -f {}" :)
Quote from: oBFusCATed on September 15, 2010, 05:46:38 PM
probably make clean should be made more brutal: "find . -iname 'Makefile' | xargs -i {} rm -f {}" :)
make distclean should do something similar as far as I know.
Quote from: jens on September 15, 2010, 06:16:29 PM
make distclean should do something similar as far as I know.
True, but that won't work, too if you did a configure already using a new setup. And in my case that's the point where I usually realise I should have done this earlier... ;-)
-------------- Build: src in Code::Blocks - Unix ---------------
Skipping file (no compiler program set): src/resources/resources.rc
g++ -Lbase/tinyxml -Ldevel -o devel/codeblocks .objs/src/app.o .objs/src/appglobals.o .objs/src/compilersettingsdlg.o .objs/src/crashhandler.o .objs/src/dlgabout.o .objs/src/dlgaboutplugin.o .objs/src/environmentsettingsdlg.o .objs/src/infopane.o .objs/src/main.o .objs/src/notebookstyles.o .objs/src/prefix.o .objs/src/printdlg.o .objs/src/scriptconsole.o .objs/src/scriptingsettingsdlg.o .objs/src/splashscreen.o .objs/src/startherepage.o .objs/src/switcherdlg.o -L/usr/lib64 -pthread -Wl,-O1 -L/usr/lib64 -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -L/usr/lib64 -pthread -Wl,-O1 -L/usr/lib64 -lwx_gtk2u_aui-2.8 -lwx_baseu-2.8 -lcodeblocks -lwxscintilla -lwxpropgrid
Output size is 4.23 MB
Is this normal? Happens with the debuggers branch on linux. After successful compilation this is printed to the log...
so I finally got a new build (cc branch) but oh boy :-(
CB is completely broken. The moment I open an editor (loading a project with an already open file, or open a project with no files open and then open a file), CB HANGS.
The mouse pointer becomes a big arrow pointing left-upwards.
Disabling CC makes the problem go away.
Next : with an editor open (and CC disabled), I re-enable the CC plug-in. No hanging, but CC doesn't seem to be really activated, for example right clicking on on include +> no entries in the menu to open it, right-clicking on a variable -> no find declaration/implementation entries.
So let's close CB, and restart it, and were back at the problem were it all started.
Emergency help needed ;-)
On linux (64 bit), rev 6596 on CC branch
Quote from: MortenMacFly on September 15, 2010, 09:02:43 PM
Quote from: jens on September 15, 2010, 06:16:29 PM
make distclean should do something similar as far as I know.
True, but that won't work, too if you did a configure already using a new setup. And in my case that's the point where I usually realise I should have done this earlier... ;-)
make distclean normally removes all Makefiles and it works for me.
Quote from: killerbot on September 15, 2010, 10:00:13 PM
so I finally got a new build (cc branch) but oh boy :-(
CB is completely broken. The moment I open an editor (loading a project with an already open file, or open a project with no files open and then open a file), CB HANGS.
The mouse pointer becomes a big arrow pointing left-upwards.
Disabling CC makes the problem go away.
Next : with an editor open (and CC disabled), I re-enable the CC plug-in. No hanging, but CC doesn't seem to be really activated, for example right clicking on on include +> no entries in the menu to open it, right-clicking on a variable -> no find declaration/implementation entries.
So let's close CB, and restart it, and were back at the problem were it all started.
Emergency help needed ;-)
On linux (64 bit), rev 6596 on CC branch
I can't reproduce this bug under Windows XP. :(
make distclean works for me too. :)
I build CB on Windows and Linux apparently without any problem. But, I don't (never) use the makefile, configure and so on, only the previous working CB nightly and the .cbp or .workspace files. Finally, CB generating itself, is a good solution, no ... :P
gd_on