replace CMAKE_* by PROJECT_* in all CMakeLists.txt

[Pompei2]

Hi,

I'm creating a project, and throwing SFML into a subdirectory of it. I plan to distribute them together and have my main CMakeLists.txt include the SFML one. (using add_subdirectory(${PROJECT_SOURCE_DIR}/sfml2))

This works well, but I had to change all CMAKE_* variables (like CMAKE_SOURCE_DIR) to PROJECT_* ones (like PROJECT_SOURCE_DIR). I think this is what you really need!

Unfortunately I cannot create a patch because I have other local changes and I am not good working with diff (selecting only some files) But it's really just a find-replace.

Or maybe am I doing something wrong?

[Laurent]

That should work because both variables point to the same location in my CMake setup, but what if one day I change it to have one CMake project per SFML module?

I think you shouldn't include SFML in your project this way. You shouldn't compile it together with your project, but if you really want to do so I'm sure there's a cleaner way to do it (maybe with imported targets?).

Why do you want to merge SFML to your project?

[Juanxo]

hi Laurent:

I have created a project, and i have to face the same problem than Pompei.

I think you can create a "fake" PROJECT_SOURCE_DIR (i currently use SFML_ROOT_DIR in my local copy), so we can include SFML directly in our projects

Perhaps:

Code: [Select]


IF (NOT SFML_ROOT_DIR)
  set( SFML_ROOT_DIR ${CMAKE_SOURCE_DIR})
ENDIF()


That way you mantains compatibility with the current way (directly using CMAKE_SOURCE_DIR), you can create one project for each module (cause SFML_ROOT will keep pointing to the same location) and we can tweak SFML compilation to fit our needs

And to answer your question about why we want to include SFML in our projects, i think it's because we want to keep all organized and dont have SFML spread out of the project

Thx for the awesome work[/code]

[Laurent]

And to answer your question about why we want to include SFML in our projects, i think it's because we want to keep all organized and dont have SFML spread out of the project

I don't get it, sorry. Are you going to recompile every library that your project uses, every time you compile the project? For every project that you develop? Or is there something special about SFML?
You're definitely not supposed to do that, in my opinion.

[Juanxo]

i dont recompile SFML every time... but i like to handle all the libraries with the same cmake project.

Perhaps it's me who don't get it. I would like to automatize at most as possible the creation of the libraries... but perhaps I'm using a bad approach.You have talked about imported dependencies. Could you elaborate about them more, or point me to the right direction about them?

[Laurent]

SFML is a library so why don't you use it as a library, ie. compile it once and then simply link to it in your project (target_link_libraries(...))?

You have talked about imported dependencies. Could you elaborate about them more, or point me to the right direction about them?

I don't know much about imported targets, you'll find more useful information with Google. But I'm not sure this is what you need.

[Juanxo]

I use them as library and I include it in my project as different libraries, but i keep the source code and all the stuff needed to build them.

Let say i clone my repository, where i have all the source code and necessary things to build my project and extlibs (SFML included).
I build with cmake and compile my project and libraries( here i have to compile SFML)

Next, i make a change in my project, build it, and only my project is built, cause SFML keeps as a separate library project.

Examples aside, i just wanted a way to tweak some values of SFML compilation without having to modify the SFML cmake files, as i have to do now every time i pull a new version.

If you want, i can give you my cmakefiles, where i have done the changes needed to do this, so you can see if it worth the change

[Laurent]

Let say i clone my repository, where i have all the source code and necessary things to build my project and extlibs (SFML included).
I build with cmake and compile my project and libraries( here i have to compile SFML)

Next, i make a change in my project, build it, and only my project is built, cause SFML keeps as a separate library project.

So why do you need to have both merged into the same CMake tree? Can't you simply build SFML first, and then your project separately?

Examples aside, i just wanted a way to tweak some values of SFML compilation without having to modify the SFML cmake files, as i have to do now every time i pull a new version.

You shouldn't have to modify the CMake files of SFML. What did you change?

[Juanxo]

Hi Laurent:

i just wanted to automatize all the build process (check sfml changes, build it, build my project and link sfml)

I just changed all cmake_source_dir, cause it points to my project dir, instead of SFML dir.

I think that if you just change al cmake_source_dir with SFML_dir or something similar, and then set it to ${CMAKE_SOURCE_DIR} if is not set by the user can give us more control over the compilation process and it would remain with the same functionality.

Also, I'm trying your suggestions, and using another script to build SFML independently, to see if there are differences with my current approach.

Thanks
Juanxo

[Laurent]

i just wanted to automatize all the build process (check sfml changes, build it, build my project and link sfml)

You can simply use a higher-level script

Code: [Select]

cd sfml
svn up

cd ../build-sfml
cmake ...
make
make install

cd ../build-project
cmake ...
make

[Juanxo]

yep, that's what i'm doing now.

Thanks for the help laurent