Edyuk : fully-featured, highly flexible and free cross-platform IDE

[fullmetalcoder]

My experience of CMake until now is limited to basic syntax (just enough to fix a CMakeList.txt when KDE 4 fails to build on my laptop) so I have not yet considered supporting CMake as a build system for Edyuk itself. If anyone is interested in contributing this that will be welcomed but one thing is certain : qmake project files won't be dropped.

[ComaWhite]

Well I started working on a cmake build of it. Almost have atleast 50% give or take finished. But boy is it confusing as fudge

[fullmetalcoder]

If you can make it work that'd be great for sure.

AFAIK the most difficult part to "port" will probably be the custom tool used to autogenerate some plugins code (the part that handles communication between plugin system and plugins themselves). I have no idea how that may be done in CMake (is it even possible?)

[ComaWhite]

Well there is one part that I had to change the name of the libedyuk dll to libedyukmain because it wouldn't allow to projects to have the same name.

What really confused me was the 3rd directory which I thought those were dll's too.

[fullmetalcoder]

the 3rdparty directory contains modules which are independent from Edyuk (and can be build as dlls) but are embedded in it to make build simpler and allows proper depedency tracking.

If you have to rename the library, edyukcore would probably be a better fit than edyukmain. Another possibility is to change the name of the executable (e.g edyukapp).

[ComaWhite]

Is there a way you can tells me which folder depends on which, and which should be built as dll or as an executable?

Edit: Somehow cmake doesn't like the way you have your qmake done. So its being a more of a pain to do
Edit2: I think the only way to go around this would be to rearrange the project around. Because the ui files in the 3rdparty directory. When I try to mimic the pri files. They build in like src/lib causing them to not compile in the 3rdparty directory. And someone cmake won't build unless those directories are dlls or executables.

[fullmetalcoder]

The most pri files use shortened pathes, which works because the DEPENDPATH variable of the pro files which include them is set accordingly. I don't know if CMake allows such a thing (the best would be a $PWD variable that would hold the path of the file being interpreted (i.e the pri not the pro) but qmake does not appear to have that).

The layout is as such :

• core library : DLL built from files in src/lib and 3rdparty/*
• executable (simple main() func calling corelib functions to launch the app) : built from files in src/exec
• tool used to generate plugin code : executable built from files in src/qplugin_generator (could probably be moved to a tools/ directory)
• plugins : each folder in src/plugins/ generates a DLL

[ktk]

Originally Posted by fullmetalcoder

The most pri files use shortened pathes, which works because the DEPENDPATH variable of the pro files which include them is set accordingly. I don't know if CMake allows such a thing (the best would be a $PWD variable that would hold the path of the file being interpreted (i.e the pri not the pro) but qmake does not appear to have that).

Last time I looked (and that was about a minute ago) qmake had that
variable, and it was called --- $$PWD!

In fact, for various reasons, it is usually advisable not to use relative paths
in .pro/.pri files at all, but to prefix every such occurrence with $$PWD.

[fullmetalcoder]

Originally Posted by ktk

Last time I looked (and that was about a minute ago) qmake had that
variable, and it was called --- $$PWD!

Well, last time I tried, and that was a couple of monthes ago, it did not behave as expected. I'll give it another try.