build settings crash fix [patch]

[petah]

opening build settings when there's no workspace loaded still crashes (despite your git fix).

Now, I know I know, I should have followed your wise advice as in:
- doctor, it hurts when I do that
- well stop doing that!


I think the real problem is that Workspace::GetProjBuildConf() doesn't return NULL but didn't want to mess with that.

cheers!

-- p

[eranif]

Yes, the problem is with

Code: Select all

Workspace::GetProjBuildConf

All these recent crashes you are experiencing is because of my latest performance improvement to the build system (not included in codelite 6.0)
The makefile generation time for CodeLite workspace (that one that actually generates makefile and not only invoke cmake && make) is down from 1.3s to 400ms

I started caching the various pointers and all these are the side effects of the cache

The real problem is now fixed in this commit https://github.com/eranif/codelite/comm ... 80fd0fe19b

Eran

[petah]

ok please make sure you have a conspicuous way to flush the cache -- gcc4.9 apparently uses many different cache hacks (including the worst - file timestamps), with bugs like removing a file in one stage when its needed by the next. I still can't find a big fat reset flag, it's bloody voodoo. My gcc49 builds always took wildly varrying time to complete, now it won't compile at all on one pc... i.e. by trying to shave off a few minutes they tripwired to infinity I'm considering a live-build running inside qemu to get deterministic results... or just mix staggered stable/testing/unstable repositories.

A damn shame cause everything else was running perfectly until then. I figured out pre-build commands can't change env variables because the .mk file is already written by then, so I wrote a $(shell $(wx-config)) type script called by the linker that adds the libstdc++ args when needed, returns and empty string otherwise.

Btw I found the source of that lldb-3.5 message, it's in:

Code: Select all

./LLDBDebugger/CMakeLists.txt:142:            message(" **** NOTICE: lldb is not available. You could try installing >= the lldb-3.5-dev (or equivalent) package")

        if (LLDB_OFFICIAL_FOUND MATCHES 0)
            message(" **** NOTICE: lldb is not available. You could try installing >= the lldb-3.5-dev (or equivalent) package")
        endif()

I'm guessing it pops up when libedit-dev is missing. It's not critical but you may want to lower the required llvm version.

cheers!

-- p

[petah]

Hi Eran,

I finally fixed the gcc49 build, its log is just short of 10K lines i.e. REAL fun to diagnose Btw I'm looking into gcc49 only to see if its regexes work so I can drop 3rd party implementations.

Until you mentioned it, I didn't consider caching while I wrote the script that inserts compiler-specific linker options:

Code: Select all

--[[
    # add to linker options
        
        $(shell $(LINK_CONF) $(ProjectName));
        
    # define CL/global env vars
    
        LINK_CONF=</absolute/path/to/linkopt.lua>
        GCC49LIB_DIR=</absolute/path/to/lib64/dir>
        
    # add to post-build commands (optional)
    
        ldd $(OutputFile) | grep -E '\blibstdc++'
]]

local wd = os.getenv("PWD")

f= io.open("wrap_link.log", "w")
assert(f)

f:write("LUA WD = "..tostring(wd).."\n\n")

---- print any arguments -------------------------------------------------------

	local n_args = #arg
	
	f:write("\nlua args: ", n_args, "\n")
	
	if (0 == n_args) then
		f:write("MISSING ARGUMENTS, aborting")
		-- ERROR
		return
	end
	
	for k, v in ipairs(arg) do
		f:write(("\targ[%d] = %s\n"):format(k, tostring(v)))
	end

	f:write("\n\n")

local ProjectName = arg[1]

---- ENV VARS ------------------------------------------------------------------

	f:write("\n\nENV VARS:\n")

	-- get shell env vars in one go
	local env_s = io.popen("env"):read("*a")
	
	f:write(env_s, "\n\n")

	-- get CL env var of gcc4.9 library dir
	local lib_dir = os.getenv("GCC49LIB_DIR")

	f:write("lib_dir: ", tostring(lib_dir), "\n\n")

---- read CL's pre-saved MAKE file ---------------------------------------------

local mk_s

do
	local ProjectMkFilename = ProjectName .. ".mk"

	local proj_f = io.open(ProjectMkFilename)

	mk_s = proj_f:read("*a")

	proj_f:close()
end

---- GCC49 CL env vars from MAKE file ------------------------------------------

f:write("\nEXTRACTED:\n")

local link_s = mk_s:match("LinkerName%s+:=(.-)\n")

f:write("linker: "..tostring(link_s), "\n")

local pat = link_s:match("(g%+%+49)$")

f:write("link pat: "..tostring(pat), "\n")

local ret = ''

-- runtime output should look like this
-- "-Wl,-rpath,/home/plaufenb/development/gcc49/lib64"
-- i.e. replace semicolons with spaces

if (pat) then
	-- explicit link not needed?
	-- ret = '-Wl,-rpath,'..lib_dir..' -lstdc++ '
	ret = '-Wl,-rpath,'..lib_dir..' '
else
	-- nop
	ret = ' '
end

f:write("ret: \""..tostring(ret), "\"\n")

f:close()

-- will get inserted into linker cmd
print(ret)

it's kindof a hack; some vars are explicit arguments, others are fetched from system env vars and others from the project.mk file CL generates.

I figured that any variables written to the make file when my script gets called can no longer be changed. Is it somehow related to caching?

Do you have some dependency graph (even scribbled on a napkin) indicating what is checked and in which order? F.ex. whether the project env vars are applied before pre-build commands or when a selected compiler change is checked / what other stages it invalidates?

thx & cheers,

-- p

edit: sory my 1st question was unclear