Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

SmartIndent refactoring question

<< < (6/8) > >>

oBFusCATed:
1. Why don't you use packages? Provided by Jens or self build
2. Why don't you use prefix (--prefix=/home/myname/software/codeblocks for example), make uninstall is known to be unreliable, especially when there are changes to the filenames
3. For cleaner builds you can use something like:

--- Code: ---./bootstrap
cd build
rm -rf *
`pwd`/../configure
make -jn
make install

--- End code ---

Most of the time I stick to 1 and I'm happy...

This time I suspect there is some misery happening in the Makefiles, which is not 100% reliable.
What happens if you use make -j1?

killerbot:
packages why ? I selfbuild CB like this for over then 7 years on linux, never any problems, and very often on more then 5-6 machines.

Why is the make uninstall not reliable ? Is it due to errors in the makefiles, could we correct it ?

Well I have done the cleanup myself as described, will do such cleanup again, and do a build with just 1 core, just to see what happens.
But it is only this SmartIndent which might have a problem, cause why would one not use the multiple cores (those 1 core days are over for me ;-)  )

I will come back with the 1 core result.

EDIT :  the one core build (aka , just : make) ==> OK, so this seems to indicate that the zipping process (??) is probably having a problem during a parallel build. Things still is, never saw any problem with the other plug-ins like that.

oBFusCATed:

--- Quote from: killerbot on November 06, 2012, 07:40:33 am ---packages why ? I selfbuild CB like this for over then 7 years on linux, never any problems, and very often on more then 5-6 machines.

--- End quote ---
Your memory is pretty short, but the forum never forgets :)
Search the forum for all the topics you've started reporting there is a build problem and it turned out you've not used the correct commands.
I doubt the number will be less than 10  ;D


--- Quote from: killerbot on November 06, 2012, 07:40:33 am ---Why is the make uninstall not reliable ? Is it due to errors in the makefiles, could we correct it ?

--- End quote ---
Because it you do "svn update; make uninstall" it will break if there are changes to the file names :)
But you can check it yourself by searching you install dir for cb files after you've done a make uninstall :)


--- Quote from: killerbot on November 06, 2012, 07:40:33 am ---... cause why would one not use the multiple cores (those 1 core days are over for me ;-)  )

--- End quote ---
Because there might be parallel make issues...

killerbot:
you are correct I have run into issues, but that was very often pch problems (which seem to be the very nature of pch builds)  :P
and probably a few I don't remember, I can't even remember which wrong commands I used (could you please point them out to me again, would be good to have my mind refreshed   ;D )


But never such problem where actually the build process itself is screwing up things (like those manifest files / zip files getting broken (?) for SmartIndent with parallel build).

Correct that the uninstall, should happen before the svn up, or we should go for more "forced cleans", eg why clean fopr example /usr/local/lib64/codeblocks file per file, have make uninstall just delete that entire directory (same for /usr/local/include/codeblocks and /usr/local/share/codeblocks) ?
In the "/usr/local/lib64/" we also have 4 files related to libcodeblocks and libwxsmith (so the can still suffer from name change, but their names seem rather stable).

So could we adjust the makefile uninstall to just remove those directories (rm -rf - wise) at the end ?

Another thing I noticed, wxsmith appears next to it like :
/usr/local/include/wxsmith/
Why is this not a subdir of codeblocks directory?

Jenna:
It might indeed be a problem with the zipping-processes.
It copies the appropriate manifest-file tomanifest.xml ancd then runs zip to pack it, if several of these steps run in parallel they might override (or try to override) the manifest.xml that is just used by another zip process.

This should be fixable by making the zip-processes depend on each other.

I will look into it as soon as possible.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version