Hello again!
Måndag den 6:e februari 2017, klockan 10:36, skrev TJ Saunders detta:
>
> > The implementation of VPATH builds is incomplete. The attached changes
> > constitute the minimal set needed to build and install with success an
> > TLS-enabled server in version 1.3.5d on OpenIndiana, i.e., Solaris 2.11.
>
> Thanks! For completeness (and for testing/verifying the patch, and
> testing it via CI), could you show the commands you use for doing an
> out-of-source build and install? I _think_ I know what they might be,
> but having confirmation would be great.
>
> > The implementation of VPATH builds is incomplete. The attached changes
> > constitute the minimal set needed to build and install with success an
> > TLS-enabled server in version 1.3.5d on OpenIndiana, i.e., Solaris 2.11.
>
> Thanks! For completeness (and for testing/verifying the patch, and
> testing it via CI), could you show the commands you use for doing an
> out-of-source build and install? I _think_ I know what they might be,
> but having confirmation would be great.
No magic, but common sense once you have tried it:
$ tar xzfproftpd-9.9.9.tar.gz
$ mkdir build
$ cd build
$ ../proftpd-9.9.9/configure --localstatedir=/var/run --enable-openssl \
--with-modules=mod_tls
[the usual output]
$ make
$ sudo make install
The parts of the patch that mention 'top_builddir' establish build location
and makes it known in the few subdirectories where it was missing, including
the additions to INCLUDES and LDFLAGS for finding intermediary products.
Finally, some install targets were not prepared sufficiently to find
pre-build products in the archive or new products located in the actual
build directory. This condensed explanation should catch the full change set.
Possibly a more elaborate choice of features could unearth one or two further
weak points, but the above pointers will help. It is really a useful mode
of building software to do so outside the source directory (Do not get
seduced by the clean up abilities of Git!), and clearly most of the needed
mechanisms were already present in your code base.
I found two non-standard behaviours while getting the install target to work.
Usually I make a two-step install when building software:
$ make DESTDIR=/tmp/blind install
[check for irregularites, partially script aided]
$ sudo make install
It turned out, however, that the main product 'proftpd' is built twice,
at first during the default target, then again during the install target,
because it is produced by linking object files and libraries once more.
Somehow I am under the impression that something is not optimal there,
but I am uncertain as exactly what is happening. Libtool?
Anyway, this is connected to your build decision that ownership of some
installed products be set/changed immediately by the install target.
The effect is that an underprivileged install is impossible, like my
test-install with 'DESTDIR=/tmp/blind'. Room for improvement? Like leaving
INSTALL_USER and INSTALL_GROUP with the values derived from the owner
of the build directory?
Best regards,
Mats Erik Andersson
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
ProFTPD Developers List
<[email protected]>
https://lists.sourceforge.net/lists/listinfo/proftp-devel
