Help!!!

[sleary78]

Hi,

I've got a codelite project and some unit tests that all build nice when they're in my local location. But when i try and get Jenkins to checkout the code and build it it all fails because the .mk files are generated with absolute paths. This is crippling!!! Help! can i get the projects to always generate .mk files with fully relative paths!!

[eranif]

I am not sure why are using Jenkins for, but in case it is needed for some kind of automation, you should use

Code: Select all

codelite-make

(its part of codelite installation)
to generate and build the project

Eran

[sleary78]

But that means i need codelite installed on all my build environments.. Which is not going happen. Seriously cant we get this ide to spit out proper makefiles.

To take you down the route of my reasons for needing (i think a very basic requirement).

1. My companies processes mandate jenkins for all builds.
2. We have a variety of build environments (Solaris 10 sparc (no codelite), Solaris 11 sparc, SUSE, RHEL5, RHEL6 and Arm support is coming).
3. Getting codelite to build on some of those environments is borderline impossible.
4. I use codelite for dev.

I would expect that codelite not produce half assed makefiles. Its not such a massive thing to ask for for it to produce relocatable makefiles. It wouldnt really matter which CI system i use its pretty useless if you need to install a whole ide just to run make.

[jfouche]

Have a look to http://codelite.org/forum/viewtopic.php ... lute#p7945.

[eranif]

Its not such a massive thing to ask for for it to produce relocatable makefiles

Well, its an open source project, we do our best within the limitation of our resources. Obviously, we can't make everyone happy
If you think you can help out by making it better, please don't hesitate to patch the sources and give us a hand ( I can guide you if you need help )

Another approach (if you don't like coding): you can create a small package that includes codelite-make and it dependencies and install that on your build machines

Eran

[Gibbon1]

I did a little experiment, moved one of my workspaces and then looked at what I needed to do to the make file to get it to build.

I was able to do a find and replace, changed the old workspace path with the new one. That worked.

I then I tried this, fixing up the lines in the make file from this

$(CC) $(SourceSwitch) "C:/projects/merging/sleep_test_move/board/syscalls.c" $(CFLAGS) $(ObjectSwitch)$(IntermediateDirectory)/board_syscalls.c$(ObjectSuffix) $(IncludePath)

To this,

$(CC) $(SourceSwitch) $(WorkspacePath)/board/syscalls.c $(CFLAGS) $(ObjectSwitch)$(IntermediateDirectory)/board_syscalls.c$(ObjectSuffix) $(IncludePath)

I was able compile this from the command line by the expedient of splating WorkspacePath so it's 'correct; for where I moved the project.

Might be a valid change to make to codelite. Since being able to do automated builds fits with modern practices. IE, the app built by codelite is part of a larger project. We do this on our embedded Linux doohickey, bunch of crap gets cross-compiled and then bundled into a tar file for deployment.

Seems like sleary78 could write a python or perl *spit* script to create a makefile with relative paths then check that in. Could then call the script as part of the post build process to keep the alternate makefile up to date. (Probably worth an afternoon and two or three cups of coffee)

[sleary78]

Thanks for the investigation.

So just for an update..

I tried compiling codelite_make. I think even just building this on other platforms is a non-starter because it depends heavily on wx 3.0 which has not made it to many platforms yet (Solaris 10's opencsw packages are still at 2.6). Its a bit frustrating that commandline tools depend on these libraries by i guess its for code reuse purposes.

My recommendation would be that the makefile be generated with the $(WorkspacePath) variable rather than absolute. That would satisfy everyone IMHO.

In the meantime i'm reduced to writing a script to edit my makefiles at build time which obviously introduces risk into a build environment.