installing libs on Windows

[Andreas Pakulat]

On 05.08.07 20:46:57, Alexander Neundorf wrote:
> On Sunday 05 August 2007 20:16, Andreas Pakulat wrote:
> ...
> > This is more or less a ping, as discussion somehow stopped without
> > result and we (win32 devs) like to get a result.
> >
> > So far its pretty obvious that nobody wants to use the full install
> > syntax all over kde as thats too much work to convert now (its also a
> > bit harder to write a script for this I think).
> >
> > So IMHO the new-macro-option is the best choice. The idea Alex had with
> > changing LIB_INSTALL_DIR, PLUGIN_INSTALL_DIR and LIBEXEC_INSTALL_DIR
> > is as tedious as changing to the full syntax. Currently packages are
> > normally built from the normal development builds, we (win32 devs) don't
> > have the time and resources to do separate builds just for packaging and
> > we already provide packages so that new developers don't have to start
> >
> > >from scratch (and don't run into the daily build-issues we still face)
> >
> > I still don't see the problem with a kde4_add_library() macro, there are
> > tons of macro's already for various things that can be done with one or
> > two lines of cmake code.
> 
> Which ones ?
> If we have such macros, I'm all for removing them. 
> (I had a look at KDE4_ADD_TEST_EXECUTABLE and merging it as an extra parameter 
> into KDE4_ADD_EXECUTABLE() is on my todo, reworking KDE4_INSTALL_(TS|PO|
> HANDBOOK) is also on my TODO).

What about that "touch-hicolor-theme" thing? And why is there
kde4_add_executable, there's add_executable already. Same thing as for
add_library/kde4_add_library - IMHO.

> > I'm including the macro proposed by PutHuhn here again and asking if
> > there are objections against adding this macro and converting
> > trunk/KDE+koffice to use this macro for its installed shared libraries?
> 
> Yes, objections.
> 1) Christian stated he sees no real need to change anything

Well, so far he's alone. I do see the need and seemingly Ralf also see's
the need to change something. Along with at least 2 more win32 devs.

> 2) users-only don't need to change the PATH if the binary Windows packages use 
> the features which are currently available

That means the packaging tool needs to get intelligent enough to copy
the right dll's into the bin/ dir.

> 3) for developers it is acceptable to adjust the PATH

Right, but what happens if a new developer installs qtcopy+kdelibs
(+deps) via packages and the builds his own app himself? Boom, it
doesn't start because the dll's are not found. Now he wonders: Why does
kwrite work, but my application not, until he finds that he needs to set
PATH.

This is confusing especially for new developers and thats something we
should avoid because this drives new developers away.

> 4) kde4_install_libraries() would suddenly hide the install location by using 
> some global variables, I don't want that,

Well, then let it take the lib and bin install dir along with the
targets. I don't see that as a problem.

> we don't have it anywhere (except 
> icons), this way it becomes less obvious what's going on, if you didn't use 
> the kde macros for some time, you have to learn again, as opposed if we stay 
> with the plain cmake macors

If I didn't use the cmake macro's for some time I'd have to learn them
as well again ;) 

Apart from that this is true for _any_ of the kde4 macro's and I don't
think this is a  problem. IMHO most cmake code is copied anyway and just
adjusted where needed.

> 5) kde4_install_libraries() would be only a partly solution.
> If we really want to hide it,

To be 100% clear: I'm not requesting to hide anything. The macro's sole
purpose is to ease the writing of cmake code to install libraries and to
ease the possible transition away from install().

> then lets go for a kde4_install((TARGETS|HEADERS|FILES) ... )

Fine with me actually. Although I don't see the need...

> which for TARGETS uses LIB/BIN_INSTALL_DIR and sets the COMPONENT
> for HEADERS it's a bit hard to say, the DESTINATION is still required, but the 
> COMPONENT could be set to Devel
> for FILES DESTINATION would be required and COMPONENT would be set to Default 
> or something like this.

That component stuff is mostly unusable - IMHO. Making that work
requires one to find discussions on the cmake list as (IIRC) its
completely undocumented how to install only 1 component. So I'm
objecting to that.

Andreas

-- 
What happened last night can happen again.