On 06.05.2011 11:00, Jean-Marc Lasgouttes wrote:
Le 05/05/2011 21:35, Peter Kümmel a écrit :
On 05.05.2011 14:55, Kornel wrote:
- NLS disabled by default

Formerly it was enabled by default, but after some discussions Peter
change it

It was too annoying to always having build all the .po stuff when you
wanna only
work on on C++ code. For installing it is needed, sure. But as default?

Then improve the po part so that it is not annoying anymore :) The
developers should by default test as many parts of LyX as possible.

Sounds reasonable.


- does not work in place by default (actually build_support_dir stuff
should be removed now, but I have no time)

Yes, I also find it annoying to always export LYX_DIR_20x.

All the variable naming and documentation could be reviewed and changed.
It would be great if the variable naming would be more autotool-like.

Yes

ATM cmake enables for all files bit we could introduce more variables, e.g.
-DLYX_MERGE_FILES=1 -DLYX_MERGE_MATHED=0
would merge all but mathed

With autotools, it is:

    o
--enable-monolithic-build[=boost,client,insets,mathed,core,tex2lyx,frontend-qt4]
      that enables monolithic build of the given parts of the source
      code. This should reduce the compilation time provided you have
      enough memory (>500MB).

Default is all. Again, I do not know who uses this detailed version.

- I do not like the weird paths where built files go. I really cannot
find my way there


Do you talk about object files, or others?

Object files

build$ find . -name \*.o

./boost/libs/signals/CMakeFiles/boost_signals.dir/__/__/__/__/__/boost/libs/signals/src/connection.cpp.o
./boost/libs/signals/CMakeFiles/boost_signals.dir/__/__/__/__/__/boost/libs/signals/src/trackable.cpp.o
./boost/libs/signals/CMakeFiles/boost_signals.dir/__/__/__/__/__/boost/libs/signals/src/slot.cpp.o
./boost/libs/signals/CMakeFiles/boost_signals.dir/__/__/__/__/__/boost/libs/signals/src/signal_base.cpp.o
./boost/libs/signals/CMakeFiles/boost_signals.dir/__/__/__/__/__/boost/libs/signals/src/named_slot_map.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/cpp_regex_traits.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/cregex.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/w32_regex_traits.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/instances.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/regex.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/fileiter.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/regex_traits_defaults.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/regex_raw_buffer.cpp.o
./boost/libs/regex/CMakeFiles/boost_regex.dir/__/__/__/__/__/boost/libs/regex/src/c_regex_traits.cpp.o
./src/client/CMakeFiles/lyxclient2.1.dir/__/__/__/__/src/client/client.cpp.o
./src/client/CMakeFiles/lyxclient2.1.dir/__/__/__/__/src/client/gettext.cpp.o
./src/client/CMakeFiles/lyxclient2.1.dir/__/__/__/__/src/client/boost.cpp.o
./src/client/CMakeFiles/lyxclient2.1.dir/__/__/__/__/src/client/Messages.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/CutAndPaste.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/Row.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/LayoutFile.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/output_plaintext.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/Encoding.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/TexStream.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/Floating.cpp.o
./src/CMakeFiles/lyx2.1.dir/__/__/__/src/LayoutModuleList.cpp.o

I think we couldn't do much here. cmake tries to re-use the path to the sources 
which
contain "../.." and replaces them by "__/__".

But it's internal to cmake. Why is it a problem to you?

Peter


Eventually, cmake without option should generate a makefile that has
reasonable defaults for everything (nls, spellcheck, build type, ...).
Extra options should be needed only for special needs.

As already mentioned at the beginning, in the repsitory I would prefer
developer defaults, which could be changed for releases.

This is what autotools do.

JMarc

Reply via email to