Re: location of .h's in library

[Andrew Suffield]

On Fri, Jun 18, 2004 at 03:13:55PM -0400, Daniel Reed wrote:
> (So, don't split by source file, but do split by component or task.)

Split your source files that way too. Then you get the "one header per
source file" effect most of the time - but it's completely
coincidental (sometimes you get several source files to one header; if
you've got several headers implemented in one source file, you're
probably doing it wrong).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: automake doesn't recognize AC_PROG_LIBTOOL

[Oliver B. Fischer]

Alexandre Duret-Lutz wrote:
Either you haven't installed libtool, or you forgot to run aclocal
prior to autoconf and automake.
Neither nor. Might it be the problem, that I have three different 
versions of libtool installed on my (freebsd) box? I have libtool 1.3 
installed as  libtool13, libtool 1.4 as libtool14 ant libtool 1.5 as 
installed as libtool15?

Regards,
Oliver Fischer

Re: AutoGen-5.6.2 w/o libxml2 build problem

[Bruce Korb]

"Deneys S. Maartens" wrote:
> 
> Hi Bruce
>
> When compiling the autogen source without having libxml2 available, and
> then doing a `make dist' creates a broken distribution package which
> does not include the xml2ag/ subdirectory.
> 
> A configure of the broken dist package fails with the following error
> message:
> 
> config.status: creating xml2ag/Makefile
> config.status: error: cannot find input file: xml2ag/Makefile.in
> 
> I've found that adding the line
> 
> DIST_SUBDIRS   = $(SUBDIRS) xml2ag
> 
> to the Makefile.am file solves this problem.  I've verified that listing
> xml2ag twice does not cause any problems.

Except, perhaps, integrity verification problems.

When you invoke, "make dist" I believe you are claiming that you wish
to construct a new distribution for some distribution-related purpose.
If you merely wish to verify that the parts that you can build are
built correctly, you would invoke, "make check".  If you are making
a distribution, then that distribution needs to be verified that all
parts of it are functional.  It would be difficult to verify the
functionality of ag2xml if you do not have libxml2.  Therefore, I
do not think it is correct to try to do a "make dist" when all components
cannot be built.

I think the question boils down to, "What is the proper way to fail a
`make dist' in a partial-product environment?"  A configure-time message
of "error: cannot find input file: xml2ag/Makefile.in" is a poor choice.
My guess is to add something like:

  AM_CONDITIONAL([FULL_BUILD],
 [if test "X${ag_cv_with_libxml2}" != Xno && \
 test "X${ag_cv_enable_shell}" != Xno
  then true ; else false ; fi])

and augment that list with any new configurable functional components.
Then add to the top level Makefile.am:

  if !FULL_BUILD
  dist : fail_dist
  fail_dist:
echo "Distributions cannot be made with a partial build" >&2
exit 1
  endif

Thoughts from either the Automake or AutoGen folks?

Regards, Bruce

Powerful weightloss now available where you are.

[Cristina I. Foster]

Hello, I have a special offer for you...
WANT TO LOSE WEIGHT?
The most powerful weightloss is now available
without prescription. All natural Adipren720
100% Money Back Guarantée!
- Lose up to 19% Total Body Weight.
- Loss of 20-35% abdominal Fat.
- Up to 300% more Weight Loss while dieting.
- Increase metabolic rate by 76.9% without Exercise.
- Reduction of 40-70% overall Fat under skin.
- Suppresses appetite for sugar.
- Burns calorized fat.
- Boost your Confidence level and Self Esteem.
Get the facts about all-natural Adipren720 



 system information 
Draft SOAP-RPC review designing mechanisms need linguistic servers 
Different rely Because contents zh-Hant results even User 
written know usable managing by so Different number 
who spell contents pattern members shared host What 
We model category believes Results: version States) situations 

Re: AM_CFLAGS in the project root?

[Baurjan Ismagulov]

Hello, Alexandre!

On Fri, Jun 18, 2004 at 08:18:33PM +0200, Alexandre Duret-Lutz wrote:
>   AC_SUBST([AM_CFLAGS], [value])

Thank you, this works! I did read about AC_SUBST, but haven't thought
about using it that way.

With kind regards,
Baurjan.

Re: location of .h's in library

[Daniel Reed]

On 2004-06-18T13:50-0500, David T Farning wrote:
) I am working on my first attempt at building a library in c using
) automake.  I would like the verify the location and use of the header
) files.  Could someone verify or correct my assumptions.
)
) 1. headers internal to the library should located in /src
) 2. those headers should be dependencies under _SOURCES =
) 3. follow normal header rules of one .h per .c
)
) 4. public prototypes should be located in /includes
) 5. these header will be installed in prefix/includes via
)   _include_DATA =
) 6. use very few public headers to prevent the need for library users
)   to need many #includes.

Your proposal may make sense for your particular project, but there is no
specific standard.

You should split your headers whichever way makes the most sense for your
project's API. Arbitrary rules like "one header per source file" do not get
you much (unless your code is already hopelessly disorganized).

Package-specific headers should probably installed using pkginclude_HEADERS,
which will default to /usr/local/include/PACKAGE/. This may include things
like primary interface headers (data types and function protocols) as well
as any internal headers needed for special purposes (modules, extensions,
etc.).

Artificially reducing the number of #includes is probably not worthwhile. If
it makes sense to break your public interface into several headers, go for
it. An example might be if your library has a "standard" or simple
interface, and an additional "advanced" interface that allows finer-grain
interaction. Another may be if your library has multiple uses, and it is
conceivable a developer may wish to use one portion but not the rest.

(So, don't split by source file, but do split by component or task.)

-- 
Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/   http://naim.n.ml.org/
"Murphy's Law is recursive. Washing your car to make it rain doesn't
work."

location of .h's in library

[David T Farning]

I am working on my first attempt at building a library in c using
automake.  I would like the verify the location and use of the header
files.  Could someone verify or correct my assumptions.

1. headers internal to the library should located in /src  
2. those headers should be dependencies under _SOURCES =
3. follow normal header rules of one .h per .c

4. public prototypes should be located in /includes
5. these header will be installed in prefix/includes via 
_include_DATA = 
6. use very few public headers to prevent the need for library users
to need many #includes.

thanks
-dtf

Re: AM_CFLAGS in the project root?

[Alexandre Duret-Lutz]

>>> "Baurjan" == Baurjan Ismagulov <[EMAIL PROTECTED]> writes:

[...]
 Baurjan> I can do this by defining AM_CFLAGS in each
 Baurjan> subdirectory. This works. However, I want to have it
 Baurjan> in one place. So I've tried to define this variable in
 Baurjan> the root directory instead of subdirectories, but in
 Baurjan> this case the generated Makefiles don't seem to use
 Baurjan> it. 

Only the root directory would use it, since variables defined in
Makefile.ams are not inherited between Makefile.ams.

However you probably know that variables AC_SUBSTed in
configure.ac are defined in all Makefiles.  So you could
define AM_CFLAGS in all your Makefiles using
  AC_SUBST([AM_CFLAGS], [value])
in configure.ac.

Note that Makefile.am definitions still have priority over
configure.ac AC_SUBSTs.  Therefore you can use AC_SUBST
to give AM_CFLAGS a global default value, and override this
definition locally in a Makefile.am if needed.
-- 
Alexandre Duret-Lutz

Re: automake doesn't recognize AC_PROG_LIBTOOL

[Alexandre Duret-Lutz]

>>> "Oliver" == Oliver B Fischer <[EMAIL PROTECTED]> writes:

[...]

 Oliver> Does someone know why automake can't find AC_PROG_LIBTOOL?

Either you haven't installed libtool, or you forgot to run aclocal
prior to autoconf and automake.
-- 
Alexandre Duret-Lutz

AM_CFLAGS in the project root?

[Baurjan Ismagulov]

Hello,

I have a project with two subdirectories. I want to override standard
CFLAGS. I can do this by defining AM_CFLAGS in each subdirectory. This
works. However, I want to have it in one place. So I've tried to define
this variable in the root directory instead of subdirectories, but in
this case the generated Makefiles don't seem to use it. How can I make
my Makefiles use it?

I'm using automake 1.7.9.

Thanks in advance,
Baurjan.

automake doesn't recognize AC_PROG_LIBTOOL

[Oliver B. Fischer]

Dear list,
at the moment I try to migrate a small project to automake/autoconf, but...
Since a small lib belongs to my project, I would like to use libtool. 
Hence I put AC_PROG_LIBTOOL in my configure.ac. If I start automake, it 
complains, that

src/c/Makefile.am:5: Libtool library used but `LIBTOOL' is undefined
src/c/Makefile.am:5:
src/c/Makefile.am:5: The usual way to define `LIBTOOL' is to add 
`AC_PROG_LIBTOOL'

Does someone know why automake can't find AC_PROG_LIBTOOL?
I use automake 1.8.5, and autoconf 2.5.9.
Oliver Fischer

unb,eatable software dea.ls

[Curtis Tipton]

Looking for extremely cheap high-quality software?
We might have just what you need.

Windows XP Professional 2002 . $50
Adobe Photoshop 7.0 .. $60
Microsoft Office XP Professional 2002  $60
Corel Draw Graphics Suite 11 . $60

and lots more...

Attachment Received Autoreply

[Virus Research]

This is an autoreply based on a message received from you. 

Thank you for your file-sample. We will review your email and either send
you a response or forward to the appropriate contact. If you have sent us a
file which contains a possible virus please insure that it is compressed in
a password protected zip file (password - infected). 
__

Please note: We sometimes receive a file that is analysed as clean, but find
later that the file was infected when it left the sender and was cleaned or
corrupted somewhere along the line. This is why it is necessary to
password-protect zip files.

Our official response time for virus samples is 48 hours (excluding
weekends). This time may be extended when samples need to be analysed by a
senior researcher. 

For faster response, try our WebImmune service at this link:
http://www.webimmune.net Submitting to WebImmune can also be very helpful if
you are having a problem submitting a file in a password-protected ZIP file,
especially if gateway AV software is stripping your file-sample. 

For sample-related issues please contact: 

UK : [EMAIL PROTECTED]
USA: [EMAIL PROTECTED] 
Europe: [EMAIL PROTECTED] 
Germany: [EMAIL PROTECTED] 
France: [EMAIL PROTECTED] 

Do not resubmit your file-sample if you have already sent it to WebImmune or
one of the above email addresses. 

Virus Research requires the following information:

*   What symptoms cause you to suspect that your machine is infected 
*   Whether any products find a virus (version number, company, results)
*   Your Virus Scan information (version number and DAT set number) 
*   System details that may be relevant about your system 
*   Your name, company name, phone number and email address if possible 
*   A list of all items contained in the package/message you are
composing 
*   An On-Demand scanner report that would show us your Scanner Engine,
DAT file and the file reported as infected if this is relevant. If you do
not know how to generate a report please contact technical support

Virus_Research accepts file-samples for analysis and possible inclusion into
AV signature DAT sets. We are also prepared to answer general virus
questions. 

All product-related questions and comments can be addressed through
technical support and customer service, including: 

*   Product installation and update questions 
*   Product usage questions 
*   Specific operating system/version questions 
*   Assistance with detection and cleaning or removal of viruses or
trojans

Contact Information for Technical Support:

US:
Corporate Customers:
Web: http://www.networkassociates.com/us/support
Phone: 888-847-8766
Consumer Products:
Web: http://www.mcafeehelp.com
Phone: 972-963-8000 

UK:
Corporate Customers:
Web: http://www.networkassociates.com/uk/support/
Phone (PrimeSupport Connect): 0870 9110010
Consumer Products:
Web: http://www.mcafeehelp.co.uk
Phone (Call-back request): 020 7949 0107   

Additional contact information for all worldwide offices can be found at the
following web-site: http://www.networkassociates.com/us/contact/home.htm

Thanks - McAfee AVERT(tm)

899540 - read it immediately

[Virus Research]

AVERT Labs - Beaverton

Current Scan Engine Version:4.3.20

Current DAT Version:4367

Thank you for your submission.


Analysis ID: 899540

File NameFindings   Detection
Type Extra
|--|
||-
talk.htm.scr|current detection |w32/[EMAIL PROTECTED]
|Virus   |no   

current detection [talk.htm.scr]


   The file received is infected and can be detected and removed with our
current DAT 
files and engine. It is recommended that you update your DAT and engine
files and scan 
your computer again. If you are not seeing this with the product you are
using, please 
speak with technical support so that they can help you determine the cause
of this 
discrepancy.


To find detailed information about viruses and other malware, please review
AVERT's
Virus Information Library:


http://vil.nai.com


In order to get the fastest possible response, you may wish to submit future

virus-samples to:


https://www.webimmune.net


In most cases it can respond almost instantly with a solution. This may also
be the
best option if you are having a problem with gateway scanners stripping your
sample
submission.


If you believe your computer is infected, but are unsure which files should
be 
submitted to AVERT for review, please visit:


http://vil.nai.com/vil/submit-sample.asp


For other virus-related information, please review the AVERT homepage at:


http://www.avertlabs.com


Support -


Virus Research accepts file-samples for analysis and possible inclusion into
AV
signature DAT sets. We are also prepared to answer general virus questions.
All
product-related questions and comments can be addressed through technical
support and  
customer service, including:


* Product installation and update questions

* Product usage questions

* Specific operating system/version questions

* Assistance with detection and cleaning or removal of viruses or trojans


Use the following link to update your DAT and scan engine to the most
current version: 

http://www.networkassociates.com/us/downloads/updates/


Use the following links to reach online technical support for NAI products -


Corporate Customers:


http://www.networkassociates.com/us/support/


Single User/Retail Customers:


http://www.mcafeehelp.com


Note -


Due to the prevalence of network gateway AV products, it is important that
all 
submissions be zipped and the zip file password-protected (password -
infected). Some  
products will reject an email that contains a virus that is not sent in this
way. In   
addition, often we receive a file that appears not to have been infected, to
find  
later that the file was infected when it left the sender, and was cleaned
somewhere
along the line.


Regards,




McAfee AVERT

A division of Network Associates, Inc