Business Assistance
Dear friend, It is with heartfelt hope that I write to seek your co-operation and assistance in the context stated below: May I first introduce myself. I am Mohammed Abacha, the eldest son of Late General Sani Abacha (former Military head of state and President of the Federal Republic of Nigeria) who died suddenly on 8th of June 1998. I will want you to read more of me on www.vanguardngr.com/articles/2002/columns/c128022003.html http://news.bbc.co.uk/1/hi/world/africa/909972.stm if you can assist me receive the sum of US$20M of our family money kept with some security companies in vaults in overseas, get back to me immediately to enable us proceed at once. The money was kept in a consignment with a Security Company overseas and I have all documents with me as of when it was deposited in a Security Vault for safekeeping. This money has been defaced for Security reasons and also to avoid it been spent by unauthorized persons. We have been deliberating on how to invest this fund abroad in a confidential manner until we came to a conclusion to invest it in the buying of estates and part of it will be used for non-speculative investments in your country. I am therefore soliciting your help to collect the consignment of money on my instruction for the release to you and after then transferred into your account. I will give you all the necessary documentations to facilitate your collection of the consignment of money personally in overseas. The government has no or will never have knowledge of this money, so there is no need to be worried about your safety. I guarantee your safety. Once I have your complete assurance that you can handle this, I will immediately send to you the relevant documents that you will provide to the security company in overseas to enable you take possession of the consignments of money. This will include certificate of deposit and letter of authorization. Meanwhile all I need from you is as follows: 1. Confirmation of your ability to handle this. 2. Your word that you will keep this business as confidential as possible at all times. 3. Your Name, address and telephone numbers for easy communication I will compensate you sincerely for your candid effort in this regard with 20% of the total amount of $20 Million US Dollars, while 5% has been set aside for minor expenses such as telephone and other bills that you might incur. The remaining 75% will be invested meaningfully for me and my family future. I look forward to your quick response while thanking you for your co-operation. Best wishes, Mohammed Abacha
Re: Fortran 9x support
Hi, I can understand keeping F77/FFLAGS/FLIBS/AC_PROG_F77 for backwards compatibility. However, the current approach is to keep using these macros and variables for f77 and use the new FC* ones only for f90 and upwards. My question is whether it is not possible to also include f77 in the FC approach? If so, this might open up a different way to go forward: - Only allow the user to use either AC_PROG_F77 or AC_PROG_FC (the old or the new way of doing fortran). - Use FFLAGS and FLIBS for both F77 and FC. This would make the FC approach compatible with GNU make which uses the FC/FFLAGS combination for compiling fortran. The fact that we only allow F77 or FC will prevent conflicts with these variables. - After some time the F77 macro/variable set might be phased out in favor of using the FC approach to do f77 compilation. Just my 2c. Regards, Sander On vrijdag, okt 3, 2003, at 20:12 Europe/Amsterdam, Steven G. Johnson wrote: Dear Automake folks, Recently, we've committed a set of patches to autoconf CVS to support newer revisions to the Fortran language standard. The current plan is to not document these (yet) in the next autoconf release, but it might be a good idea to start thinking about how to support these in automake, especially if revisions to the autoconf macros are required. I've attached a draft of the documentation for the new macros. The basic idea is to divide Fortran support into two categories: legacy Fortran 77, and modern Fortran: * For legacy F77 code, there are the current AC_PROG_F77 etc. macros to find $F77, $FFLAGS, $FLIBS, and so on. * For newer Fortran dialects, the idea is to treat them more like C and C++, in that we don't attempt to have separate macros and variables for separate language versions going forward. Instead, there are a new set of macros AC_PROG_FC, etcetera (just like the F77 macros with s/F77/FC/) to find output variables $FC, $FCFLAGS, $FCLIBS, etcetera. Basically, automake should just compile .f90, .f95, etcetera files with these new output variables. There is one additional twist: some Fortran compilers (xlf, ifc) expect all source files to end with .f, and require a special flag for other extensions (even "standard" ones like .f90). So, there is a new autoconf macro AC_FC_SRCEXT to figure out how to do this. For each source-file extension required, the user should call it, e.g.: AC_FC_SRCEXT(f90) AC_FC_SRCEXT(f95) ... This defines output variables $FCFLAGS_f90, $FCFLAGS_f95, ... that you can use to compile .f90 and .f95 files. Due to compiler quirks, however, these flags must appear immediately before the source file to be compiled (and only one source file can be compiled at a time). For example, you might do: foo.o: foo.f90 $(FC) -c $(FCFLAGS) $(FCFLAGS_f90) foo.f90 Cordially, Steven G. Johnson
Re: managing subdirectories
On Wed, Oct 08, 2003 at 11:12:07AM +0200, Kai Ludwig wrote:
> if test "x$gui" = xtrue; then
> AC_CONFIG_SUBDIRS(Utilities GUI)
> else
> if test "x$model" = xtrue; then
> AC_CONFIG_SUBDIRS(Model)
> else
> AC_CONFIG_SUBDIRS(Utilities GUI Model)
> fi
> fi
> configure.in:29: error: `Utilities' is already registered with
> AC_CONFIG_SUBDIRS.
> /usr/local/src/autoconf/autoconf-2.57/lib/autoconf/status.m4:1073:
> AC_CONFIG_SUBDIRS is expanded from...
> configure.in:29: the top level
I think here the problem is space characters in a SUBDIRS value.
Try to us AC_CONFIG_SUBDIRS("Utilities GUI") or something like it
But, may be I wrong
e
Do you sell in Germany?
Inexpensive attractive offices near Frankfurt, Germany Do you need an office in Europe? It couldn't be easier: Everything you need is ready for you right now. You can choose from bare office space to fully-equipped with everything. Short or long term rental. If you want a base to market to Europe, this is an ideal location. Central for Germany and France, Netherlands, Belgium, Switzerland, Czechoslovakia Austria, within easy reach. A massive market for you. Broadband, networked, desks, computers, furniture, English-speaking assistants, marketing help, translation, free parking, apartment accommodation also available. Space for 1 to 40 people, 200 to 2000 sq ft 25 mins from Frankfurt airport. ½ mile to main North South Autobahn and high-speed train service. This office space represents exceptionally good value, newly-built, fully equipped and inexpensive. Please give me a call for further info. Steve Weiss Tel: +44 (0)1481 720 294 Fax: +44 (0)1481 720 317
Re: Fortran 9x support
On Thu, 9 Oct 2003, Sander Niemeijer wrote: > I can understand keeping F77/FFLAGS/FLIBS/AC_PROG_F77 for backwards > compatibility. However, the current approach is to keep using these > macros and variables for f77 and use the new FC* ones only for f90 and > upwards. My question is whether it is not possible to also include f77 > in the FC approach? It depends on what you mean. If you have F77 code that is compatible with the latest Fortran standards, sure, you can compile it with $FC. > - Only allow the user to use either AC_PROG_F77 or AC_PROG_FC (the old > or the new way of doing fortran). I think you are missing the point here. The reason for keeping F77, FFLAGS, etcetera, is not just for compatibility with old Makefile.in files. The reason is that Fortran 77 and Fortran 9x are essentially different languages, and a number of people need to compile both in the same project, using separate compilers and flags. (This issue came up whenever Fortran 9x support was discussed on the autoconf mailing list.) So, it is essential that a user be able to call both AC_PROG_F77 and AC_PROG_FC simultaneously. This was the design goal (otherwise, AC_PROG_FC would just be an alias for AC_PROG_F77.) Steven
Agenda Juridica 2004
Title: Agenda Juridica AGENDA JURÍDICA 2004 - Encadernação de luxo LEVE, PRÁTICA E FUNCIONAL Um produto com a garantia do EMENTÁRIO FORENSE Desde 1948 servindo aos Profissionais de Direito Agenda Jurídica 2004 Dados Pessoais Calendários Prazos CPC Seccionais da OAB Justiça Federal Tribunais de Justiça Tribunais Regionais do Trabalho Calendário Mensal Audiências Agenda Telefônica Preço unitário: R$ 25,00 ESCOLHA A OPÇÃO DE COMPRA Preencha, imprima o formulário abaixo e devolva por FAX ou postal, juntando o comprovante de depósito ou cheque nominal. 1ª OPÇÃO: Depósito em conta corrente desta Editora. Escolha o banco: BANCO DO BRASIL S/A - Agência 0087-6 - Conta corrente nº 9003-4 BANCO REAL S/A - Agência 0453 - Conta corrente nº 5718604-3 BRADESCO S/A - Agência 2509 - Conta Corrente nº 40923-5 2ª OPÇÃO: Cheque nominal a EDITORA MUNDO FORENSE LTDA. Envie por carta para nosso endereço abaixo: Agenda 2004 Editora Mundo Forense Ltda. Rua da Lapa, 180 s/809 20021-180 - RIO DE JANEIRO - RJ 3ª OPÇÂO: Receba gratuitamente esta agenda adquirindo o CD-ROM EMFOR - Tradicional Banco de Dados EMENTÁRIO FORENSE - Ano LV Faça o pedido pelo nosso site - www.emfor.com.br PEDIDO A EDITORA MUNDO FORENSE LTDA CNPJ 03.305.769/0001-06 Solicito a remessa de (mencionar a quantidade) AGENDA(S) EMFOR para o endereço abaixo. Nome: Empresa: Endereço de Entrega: Cidade: Estado: CEP: CIC/CNPJ: Inscr. Est: Tel: E-mail: Remessa via postal com Registro para seu endereço. Prazo de entrega:15 dias úteis após o recebimento do pedido Pedidos & Informações Tel.: 21.2556-9879 FAX: 21.2285-7864 E-mail: [EMAIL PROTECTED] CASO NÃO O QUEIRA RECEBER NOVAMENTE, RESPONDA ESSA MENSAGEM COM ASSUNTO REMOVER OU Clique Aqui
automake-1.7.7 and AM_CFLAGS/CFLAGS
I have an automake/autoconf package that builds "normal" software and also kernel modules. "configure" builds a default set of CFLAGS that gets used to build general software. The problem is that the Makefile.am for any kernel code needs to use different CFLAGS, and when automake sees this we get the: `CFLAGS' is a user variable, you should not override it; use `AM_CFLAGS' instead. This application has thousands of Makefile.am's - any ideas on a good way to fix this problem? H
Re: automake-1.7.7 and AM_CFLAGS/CFLAGS
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: [...] Harlan> The problem is that the Makefile.am for any kernel code needs to use Harlan> different CFLAGS, and when automake sees this we get the: Harlan> `CFLAGS' is a user variable, you should not override it; Harlan> use `AM_CFLAGS' instead. Harlan> This application has thousands of Makefile.am's - any Harlan> ideas on a good way to fix this problem? I don't know if any of these will be "good" for you, but here are three ideas: put `AUTOMAKE_OPTIONS = -Wno-gnu' in all the affected Makefile.am, or a use global `AM_INIT_AUTOMAKE([-Wno-gnu])', or try to gather all kernel modules inside a subpackage with its own configure and different CFLAGS. -- Alexandre Duret-Lutz
Re: automake-1.7.7 and AM_CFLAGS/CFLAGS
Thanks, if it comes down to it I'll put AUTOMAKE_OPTIONS=-Wno-gnu in the affected Makefile.am's. I'm trying hard to keep the warnings, as I want the developers to write cleaner code... H
How can I create a different file type ??
Hi, I have a package that uses autoconf/automake. There are some man pages in $top_srcdir/man/man1. There are also html formatted versions of the man pages in $top_srcdir/docs/html-docs, with the extention.html appended. So if the man page is foo.1, the html-formatted version is foo.1.html I create the html formatted pages from the man pages using a utility 'man2html' which is on the web. Is there an obvious way of ensuring the html files get updated if the man pages do? I don't intend distributing man2html, so just want to be sure that me (the maintainer) forces an update of the html formatted man pages if I update the normal ones. I know producing html from man pages is not the best way, but it works (sort-of). -- "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge. Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Website: http://www.medphys.ucl.ac.uk/~davek Author of 'atlc' http://atlc.sourceforge.net/
