installing libs on Windows

[Alexander Neundorf]

On Sunday 05 August 2007 21:09, Andreas Pakulat wrote:
> 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

Nobody knows what you have to do to update an icon cache, so there is clearly 
the need to give it a name. Beside that, I think it would be a good idea to 
create a FindXdgUtils.cmake and move it there.

> kde4_add_executable, there's add_executable already. Same thing as for
> add_library/kde4_add_library - IMHO.

They do a lot, they handle enable_final, automoc and RPATH.

> > > 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.

I consider Christians opinion as important, if he says there is no real need 
to, it means at least that it can't be that bad as it is now.

> > 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.

I don't want to change anything in the cmake files because the way the 
packages are currently built. I'd like to get a response to that first before 
changing it for this reason.

> > 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.

We have pros and cons, and until know there was no patch with enough pros. 
Finding out that some app doesn't start because it can't find the dlls should 
be something a KDE developer on Windows should be able to find out.

> 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.

Please explain, I don't understand.

> > 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...

The component stuff.

> > 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. 

It's right that the COMPONENT stuff is currently more or less undocumented 
(that's the reason why I wrote on the cmake list it is experimental, but I 
was wrong with that), but nevertheless it works and is supported also by 
CPack (which can now also create debian packages). 
Installing one component can not be done via a make target, but you can call 
the cmake_install.cmake script manually and set the component there.
Note the difference difference between "I don't know how to use it" and "it is 
unusable".

Introducing a macro which helps with some bits but isn't good enough to give 
us the full power of the cmake install commands is no good option.

Ideally we would have:

install(TARGETS kde4-config kdecore 
                   RUNTIME DESTINATION ${BIN_INSTALL_DIR} COMPONENT Default
                   LIBRARY DESTINATION ${LIB_INSTALL_DIR} COMPONENT Default
                   ARCHIVE DESTINATION ${LIB_INSTALL_DIR} COMPONENT Devel)

# may need subdirectories:
install(FILES kurl.h 
        DESTINATION ${INCLUDE_INSTALL_DIR}/kdecore COMPONENT Devel)

# can go to any directories:
install(FILES data.xml DESTINATION ${DATA_INSTALL_DIR} COMPONENT Default)

install(PROGRAMS foo.pl DESTINATION ${BIN_INSTALL_DIR} COMPONENT Default)

Then it would be easier for packagers to create user and devel packages. If we 
introduce some macro to hide the install stuff then it should do all that for 
us.

> 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.

So clearly we have no consensus and no strong need to change something. 

Bye
Alex