installing libs on Windows

[Andreas Pakulat]

On 05.08.07 23:52:39, Alexander Neundorf wrote:
> 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:
> > > > 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.

Sure its not that bad, we currently are developers that know how to set a
PATH. For an end user that is unacceptable and there are only 3 ways
to make it work for him:

a) make the installer change the PATH in the users environment settings,
which breaks installing the .zip files directly into some dir or moving
the programs later on
b) provide wrappers which will search the dll's and set PATH before
executing the real executable. Which means either hiding the real
executables in some dir (which the packager would have to do) or facing
bugreports about non-working apps because the user started the .exe
instead of the .bat file.
c) change the packaging tool to copy the dll's over, which has the
drawback of differences between installed from package and from source
modules, which will confuse new developers I think.

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

Sorry, I don't understand you here. To which question/statement do you
want a response? Its not that hard to change the packaging tool, but it
gets confusing when you mix package and source installs.

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

Right, because all KDE developers are god-programmers from the start.
This is a completely wrong assumption if KDE wants to attract new
contributors, you can't assume that somebody who wants to start hacking
on kde/win32 already has win32 development experience.

I currently mentor a SoC student who didn't have any idea about CMake or
KDE before that but is very interested in contributing also after SoC.
He had a quite hard time already setting up his build environment under
Linux, I wouldn't dare trying to get him to a windows box.

Maybe I misunderstand the reasoning for macros, but I thought its to
"share code" and make the life of developers more easy. Which the
proposed patch does, IMHO.

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

I mean:

kde4_install_library(foolib ${LIB_INSTALL_DIR} ${BIN_INSTALL_DIR})

then you don't hide anything. Of course that makes a bit more sense with
a kde4_install_targets.

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

Ok, so this (calling cmake_install script manually) is not needed
because this is an experimental feature but because of the design of the
Makefile's. Then I take my statement back and say that its just
underdocumented :)

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

To me that doesn't sound like a terrible idea, even if it hides certain
things from the developer it makes his life a bit easier as well.

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

Unfortunately.

Andreas

-- 
You have a strong appeal for members of the opposite sex.