On 25 April 2015 at 00:04, Arthur Schwarz wrote:
>
> In 15.3.3.1 Command-line arguments for test drivers
>
> --log-file=PATH.log
>
> The .log file the test driver must create (see Basics of test metadata).
> If it has a directory component (as in e.g., sub/foo.log), the test harness
> will ens
* Jef Driesen wrote on Thu, Oct 09, 2008 at 05:26:46PM CEST:
> Ralf Wildenhues wrote:
>> * Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>>> BTW, what is the reason that when I use mylib_la_CFLAGS =
>>> -DMYLIB_BUILD, in Makefile.am, all my object files are named
>>> "mylib_la-myfil
Ralf Wildenhues wrote:
* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
I am shipping the symbols file. In my Makefile.am, I have
EXTRA_DIST = mylib.symbol
to make sure the file is included in the tarball.
But with this approach, msvc users will need to (manually) generate a
DEF
* Jef Driesen wrote on Wed, Oct 08, 2008 at 10:24:46AM CEST:
>
> I am shipping the symbols file. In my Makefile.am, I have
>
> EXTRA_DIST = mylib.symbol
>
> to make sure the file is included in the tarball.
>
> But with this approach, msvc users will need to (manually) generate a
> DEF file from
Ralf Wildenhues wrote:
* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
mylib.exp: mylib.symbols
if XYZ
$(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
else
$(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
endif
CLEANFILES = mylib.exp
EXTRA_DIST = mylib.
* Jef Driesen wrote on Thu, Oct 02, 2008 at 05:08:55PM CEST:
>
> mylib.exp: mylib.symbols
> if XYZ
> $(CPP) -P -DMYLIB_XYZ_SUPPORT - < mylib.symbols | sed -e '/^$$/d' > $@
> else
> $(CPP) -P - < mylib.symbols | sed -e '/^$$/d' > $@
> endif
>
> CLEANFILES = mylib.exp
> EXTRA_DIST = mylib.symbol
Ralf Wildenhues wrote:
Hello Jef,
* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
Brian Dessent wrote:
There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]
Now that I start to understand all the differences, I only need to find
a way how to incorpora
Hello Jef,
* Jef Driesen wrote on Tue, Sep 23, 2008 at 08:44:47PM CEST:
> Brian Dessent wrote:
>> There are two aspects to the symbol visibility stuff:
[ snip nice explanation ]
> Now that I start to understand all the differences, I only need to find
> a way how to incorporate everything nicel
Brian Dessent wrote:
Jef Driesen wrote:
And how about gcc < 4.0 that do not support the visibility attributes?
Is there a way to hide non-public symbols? Is the version script still
available in this case? Is it possible to use both the attributes and
the -export-symbols together?
There are t
Jef Driesen wrote:
> And how about gcc < 4.0 that do not support the visibility attributes?
> Is there a way to hide non-public symbols? Is the version script still
> available in this case? Is it possible to use both the attributes and
> the -export-symbols together?
There are two aspects to the
Brian Dessent wrote:
Jef Driesen wrote:
The MSDN documentation [1] about this issue, gives me the impression
that applications have to relink when new symbols are added to the
library (when not using a DEF). And that's something I would like to
avoid. Actually this statement surprises me, so I'
* Brian Dessent wrote on Fri, Sep 19, 2008 at 05:18:08PM CEST:
> Jef Driesen wrote:
>
> > The preprocessor stuff is automated. I only have to maintain a symbols
> > file with a few #ifdef's in it:
> >
> > mylib_abc
> > #ifdef MYLIB_XYZ_SUPPORT
> > mylib_xyz
> > #endif
>
> But it's still two
Jef Driesen wrote:
> The MSDN documentation [1] about this issue, gives me the impression
> that applications have to relink when new symbols are added to the
> library (when not using a DEF). And that's something I would like to
> avoid. Actually this statement surprises me, so I'm probably just
Brian Dessent wrote:
Jef Driesen wrote:
What are the (dis)advantages of each method? I see differences in usage
(see below), but are there technical differences as well?
It sounds like you already are aware of all the tradeoffs. I don't
think there's a technical difference in the end, i.e. t
Jef Driesen wrote:
> What are the (dis)advantages of each method? I see differences in usage
> (see below), but are there technical differences as well?
It sounds like you already are aware of all the tradeoffs. I don't
think there's a technical difference in the end, i.e. the results are
the sa
* NightStrike wrote on Wed, Mar 19, 2008 at 07:02:17PM CET:
> On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Mar 2008, NightStrike wrote:
> > >
> > > I had intended to do everything with non-recursive make, but as you
> > > pointed out once, non-recursive is also considered h
Hi,
On Wed, Mar 19, 2008 at 03:55:55PM -0400, NightStrike wrote:
> > mingw-w64/crt
> > mingw-w64/doc
> > mingw-w64/hdr
...
> So I guess the choices boil down to:
>
> 1) Change the directory structure
> 2) Recursive make to a small degree
>
> Is that about right?
actually, I recommend recursive
On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote:
> > On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> > > BTW: Why do you insist on the layout described above? I would have
> > > one top-level directory and make "doc
Hello,
On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote:
> On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> > BTW: Why do you insist on the layout described above? I would have
> > one top-level directory and make "doc" and "headers" (or perhaps
> > "hdr") subdirs.
>
> The mingw-
On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> BTW: Why do you insist on the layout described above? I would have
> one top-level directory and make "doc" and "headers" (or perhaps
> "hdr") subdirs.
The mingw-w64-headers directory contains headers that are required to
use the resulting gcc
Good afternon Della,
On Wed, Mar 19, 2008 at 02:02:17PM -0400, NightStrike wrote:
> > On Tue, 11 Mar 2008, NightStrike wrote:
> > > I had intended to do everything with non-recursive make, but as [Ralf]
> > > pointed out once, non-recursive is also considered harmful.
[thread:]
> http://lists.gnu.
On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2008, NightStrike wrote:
> >
> > I think I understand what you mean. Create a recursive build tree
> > that allows starting from any point. I would then perhaps put this
> > also in the trunk/Makefile.am:
> >
> > EXTRA_DIST=m
On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2008, NightStrike wrote:
> >
> > I think I understand what you mean. Create a recursive build tree
> > that allows starting from any point. I would then perhaps put this
> > also in the trunk/Makefile.am:
> >
> > EXTRA_DIST=m
On Tue, 11 Mar 2008, NightStrike wrote:
I think I understand what you mean. Create a recursive build tree
that allows starting from any point. I would then perhaps put this
also in the trunk/Makefile.am:
EXTRA_DIST=mingw-w64-headers mingw-w64-doc
So that from the trunk directory, I could run
On Tue, Mar 11, 2008 at 5:41 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Mon, Mar 10, 2008 at 03:42:52PM CET:
>
> > Our project is laid out like this:
> >
> > /trunk/
> > /trunk/mingw-w64-crt/
> > /trunk/mingw-w64-doc/
> > /trunk/mingw-w64-headers/
>
>
> > What is t
* NightStrike wrote on Mon, Mar 10, 2008 at 03:42:52PM CET:
> Our project is laid out like this:
>
> /trunk/
> /trunk/mingw-w64-crt/
> /trunk/mingw-w64-doc/
> /trunk/mingw-w64-headers/
> What is the best way to handle this situation to remove the need to
> manually tar up the trunk?
Move the (to
Am Sonntag, den 11.02.2007, 23:24 -0300 schrieb Matías Alejandro
Torres:
[..]
> I figure out my two questions... almost, let's say I want to copy one
> whole directory recursively
>
> Makefile.am
>
> contactsdatadir = ${prefix}/share/applications/contacts
> contactsdata_DATA = \
> themes
Matías Alejandro Torres escribió:
Hi all
I'm using anjuta for generating the configure, make and make install
needed files for a program of my own. After doing these i discover
that... it configures and builds okey, it even checks for the needed
libraries. Great so far.
Anyway .. I have a
> "David" == Masterson, David <[EMAIL PROTECTED]> writes:
David> * Does Automake assume that Info files should be part of the
David> distribution of a package (ie. "make dist")?
Yes.
David> ** If so, why?
GNU coding standards
David> ** Is there a means to specify that Info files should *n
29 matches
Mail list logo
