On Wed, 24 Jan 2018, netfab wrote:
Ok, killed SUBDIRS :
https://framagit.org/netfab/GLogiK/commit/c3a88a89b486aa45e9f6b462e11b4f2c96812709
But, still the same error when running make distcheck :
make[2]: Entering directory '/home/netfab/dev/projects/GLogiK/build'
make[2]: *** No
Le 24/01/18 à 14:13, Bob Friesenhahn a tapoté :
> Have you made sure that the distribution tarball is packaging up this
> header file?
How do I check this ? I do not have any tarball.
Make distcheck should create the tarball, and unpack it to run the
build into separate directory.
From ⁽¹⁾ :
>
Le 24/01/18 à 17:04, netfab a tapoté :
> Le 24/01/18 à 17:01, Václav Haisman a tapoté :
> > Looking at your Makefile.am,
> > [...]
> > without using SUBDIRS. It improves build parallelism.
>
> Thanks, I will look into it.
>
Ok, killed SUBDIRS :
On Wed, 24 Jan 2018, netfab wrote:
Le 24/01/18 à 14:13, Bob Friesenhahn a tapoté :
Have you made sure that the distribution tarball is packaging up this
header file?
How do I check this ? I do not have any tarball.
Make distcheck should create the tarball, and unpack it to run the
build into
Hi,
On 1/24/18, netfab wrote:
> Into that project, there's a subdirectory to build a library using
> libtool-2.4.6. The source code of this library is organized into
> sub-directories, like this :
>> mylib/makefile.am
>> mylib/aaa.cpp
>> mylib/aaa.h
>>
I came across one project in which install-strip doesn't strip the
shared library: liblink-grammar.so in
https://github.com/opencog/link-grammar
As an opposite example, showing the normal behavior, install-strip
strips libexpat.so in
https://github.com/libexpat/libexpat/tree/master/expat.
Hi,
I'm using automake-1.15.1 to build a project using recursive makefiles.
Into that project, there's a subdirectory to build a library using
libtool-2.4.6. The source code of this library is organized into
sub-directories, like this :
> mylib/makefile.am
> mylib/aaa.cpp
>
Le 24/01/18 à 09:09, Nick Bowler a tapoté :
> Since you are hitting this problem now, you have probably only been
> testing in-tree builds until this moment.
In fact, no. Since the beginning I'm using a separate build directory.
But I did not test distcheck since I've added these lib
Le 24/01/18 à 16:16, Václav Haisman a tapoté :
> > The makefile.am for this lib contains :
> >> libmyLIB_la_SOURCES = \
> >> aaa.cpp aaa.h \
> >> foo/bbb.cpp foo/bbb.h \
> >> bar/ccc.cpp bar/ccc.h
>
> What if you use %D%/aaa.cpp %D%/foo/bbb.cpp etc.?
What is %D% ?
On 24 January 2018 at 16:37, netfab wrote:
> Le 24/01/18 à 16:16, Václav Haisman a tapoté :
>> > The makefile.am for this lib contains :
>> >> libmyLIB_la_SOURCES = \
>> >> aaa.cpp aaa.h \
>> >> foo/bbb.cpp foo/bbb.h \
>> >> bar/ccc.cpp bar/ccc.h
>>
>>
Le 24/01/18 à 17:01, Václav Haisman a tapoté :
> Looking at your Makefile.am, I would suggest to change it a bit and
> avoid SUBDIRS entirely, if you can. See
> https://github.com/log4cplus/log4cplus/blob/master/Makefile.am and
> https://github.com/log4cplus/log4cplus/blob/master/src/Makefile.am
On 24 January 2018 at 11:38, netfab wrote:
>
> Hi,
>
> I'm using automake-1.15.1 to build a project using recursive makefiles.
>
> Into that project, there's a subdirectory to build a library using
> libtool-2.4.6. The source code of this library is organized into
>
On 24 January 2018 at 16:26, netfab wrote:
> Le 24/01/18 à 09:09, Nick Bowler a tapoté :
>> Since you are hitting this problem now, you have probably only been
>> testing in-tree builds until this moment.
>
> In fact, no. Since the beginning I'm using a separate build
13 matches
Mail list logo