Forum OpenACS Q&A: Makefile Help

Posted by Roberto Mello on
Hi all,

So I revamped the pgdriver Makefile to comply to the AOLserver modules Makefile standard. And it works. I was able to cut down the Makefile size to a third. Instead of putting architecture specific lines in the pgdriver Makefile, I just used the AOLserver Makefile.module, just like every other module.

I'm preparing an aolserver3.3+ad13 tarball that will compile everything an OpenACS 4 user needs by simply running "./".

However, I'm having a problem with a Makefile. I know this is something very simple but I'm stomped. I hereby invoke the Makefiles gods to come in my aid:

if [ -d "/usr/local/pgsql" ]; then 
    # Location of the PostgreSQL libraries
    PGLIB = /usr/local/pgsql/lib
    # Location of the PostgreSQL includes
    PGINC = /usr/local/pgsql/include;
    # Locations on a LSB-compliant distribution

The error I get is this:

makefile:27: *** missing separator.  Stop.
27 is the line where the "if" statement starts. Thanks in advance.
2: Response to Makefile Help (response to 1)
Posted by Marc Spitzer on
the location of postgres 7.1.2_2 include files is /usr/local/include/pgsql and the lib files are in /usr/local/lib for freebsd by default, I think this changed with postgres 7.1.  The data files are stored in /usr/local/pgsql though so your check could be a problem.  I have no great experence with Makefiles but could the problem be above the 'if' line.  could there be some spaces for tabs above it?

ps I was not finding fault with your work but just trying to point out a potential problem.  Thank you for doing it BTW.

3: Response to Makefile Help (response to 1)
Posted by Todd Gillespie on
I see that error if I don't have an if block under a target block.  Could you post a larger section of the Makefile in question for more context?  Also, are some characters stripped out by bboard?
4: Response to Makefile Help (response to 1)
Posted by Jonathan Marsden on
Roberto, the code you poted looks more like code from a shell script than from a Makefile.  TAB at the start of lines really really matters in Makefiles... is that (part of) the problem?

Maybe you can actually put this code into your .sh file (since you seem to have one anyway!), and then just call make with these env vars already set appropriately?

Separate issue: does your tarball include Henry's internationalization patches, and/or an nsd.tcl with the parameters for them in place?  Should it have that stuff in there?

5: Response to Makefile Help (response to 1)
Posted by Roberto Mello on
I posted the makefile at

I realize the right way would be to have a configure script that would let the use specify the location for his PG installation, but we're not there yet. I wonder how hard it would be to make AOLserver build with autoconf.

Your brought a good point. My tarball is just AOLserver 3.3ad13 with nsxml and the PG driver also being built and with a shell script that builds it all for you. I thought ad13 had internationalization stuff built-in already. Is Henry's patches for AOLserver or just something for the config file? I'll include it definitely.

I'll look through the latest Henry's posts and try to figure out. Thanks for reminding me.

6: Response to Makefile Help (response to 1)
Posted by Roberto Mello on
Where are Henry's patches? I can't find it on his posts.
7: Response to Makefile Help (response to 1)
Posted by Todd Gillespie on
Jonathan is correct. You are confusing shell script with makefiles. You cannot run arbitrary commands in makefiles, and there are only a subset of the tests available from the shell syntax. So anyway, I assumed this might work:
ifndef PGLIB
        if [ -d "/usr/local/pgsql" ]; then 
                export PGLIB=/usr/local/pgsql/lib; 
                export PGLIB=/usr/lib 
but it turns out that the fragment of script above is executed in its own 'sh -c', and can't assign variables to the makefile. Moreover, IIAC, makefile 'variables' can only be target definitions.

Eventually one has to give up and start working with autoconf/automake.

Posted by Roberto Mello on
Okay, I seem to have made it work with the help of fellow #openacs'ers, especially Mark, Gilbert and Psychephylax. (BTW, those not on #openacs at are missing out. Lots of learning happen in that channel).

I made this tarball so that it would be easier for people to build all the AOLserver modules necessary for usage with OpenACS 4. That does NOT mean it is officially "endorsed" by the OpenACS project (it is not yet), but it may in the future.

So if you'd like to help me test this, especially in architectures/OS's other than Intel/Linux that'd be great. I made a README and INSTALL files that should explain what needs to be done, but basically:

- untar

- cd aolserver3_3_ad13/root/arsdigita-aol3

- ./

This will make AOLserver and all the modules we need, including nsxml and I did not include the Oracle driver in the build because I'm tired of messing with makefiles. We should really support autoconf/automake. But it's easy to build the Oracle driver by hand.

So please help me smoke test this. Read the README and INSTALL files.

9: Response to Makefile Help (response to 1)
Posted by Roberto Mello on
Oh, also, it'd be great if someone better at Makefiles and more acquainted with the PG driver could look at the revamped makefile for the driver. It builds okay for me.
10: My I18N Patches (response to 1)
Posted by Henry Minsky on

Here's the story with the patches I made for ACS 3.2.5: There were two kinds of patches; some patches for AOLserver, and some patches for ACS.

1) All the code that needed to be patched into the AOLserver executable or tcl library was folded into the ad+13 release by Rob Mayoff.

They were basically just a patch to ns_getform to make sure that the POST (or GET) data was stored in "raw binary" and then to allow you to request the form data in a specific character set (i.e., if the user submitted a form encoded in Shift_JIS, I need to tell ns_getform to convert the form data from Shift_JIS into Unicode before it gives it to my application or to ad_page_contract, etc).

2) The patch also has Tcl code for patching ACS so that it explicitly does character set conversions in places such as were described above, where a .html or .tcl or .adp file is loaded from the filesystem into Tcl. In all these cases, you must specify what encoding conversion to use when the file is read into a Tcl string. Otherwise, the default system encoding will be used, and that may not be what you want (although usually the system encoding is ISO-8859-1, so I am a little confused by why people are having trouble with that encoding). Actually in some cases the .adp processor expects UTF8 by default, so that could confuse people.

Anyway, the bottom line is that the patches to AOLserver are no longer needed, if you have AOLserver v ad+13.

The patches for ACS are available here:

The basic approach of the ACS patch is to set up the MIME type table for files that you want to serve to include an explicit character set, i.e.,

ns_section "ns/mimetypes"
        ns_param   default         "*/*"     ;# MIME type for unknown extension
        ns_param   noextension     "*/*"     ;# MIME type for missing extension
        #ns_param   ".xls"         "application/''
        ns_param .html "text/html; charset=shift_jis"
        ns_param .tcl "text/html; charset=shift_jis"
        ns_param .adp "text/html; charset=shift_jis"

in your init file

Then, the patches are supposed to make ACS look up the MIME type for files when it is handling them in various places, and try to interpret the charset to the specified one (both when it loads the files from disk, and when it outputs them to the client browser).

But warning: these patches for ACS 3.2.5 are hardcoded for shift_jis is a bunch of places. The approach was to allow the whole site to work in a specific character set by default. The constant string "shift_jis" could be replaced by a function or global parameter variable if you want. But I was extremely lazy and left it hardcoded all over the place in the patches.

Posted by Henry Minsky on
For ACS 4, the package "ACS Localization Utils" contains similar patches to ACS to make it more "character set aware" in terms of checking the MIME type of files and trying to explicitly load and output them in the specified charset, if it exists.

These patches should probably get folded into the ACS core at some point, I just wanted to wait until there was a stable OpenACS4 release before messing with that.

Posted by Jonathan Marsden on
Henry's patchfile openacs-japanese-325-patches seems to contain quite a few changes which are not i18n related too. Probably stuff he had changed in his local copy of OpenACS 3.2.5 and forgotten about? Including the infamous "let Ben see everything" change to sdm_check_admin which gives userid 4 extra priviledges, for example.

I am going through this patchset trying to pare them down to just the i18n patches. I can attempt to parameterize the "shift-jis" string constants while I am about it.

BTW, Henry, the problem (well, OK, one problem!) with Latin-1 is that strings get created as UTF-8 by nsd8x after regexp (for example) and if they are then sent to the client using ns_write rather than ns_return... the client is sent the UTF-8, but with a content-type header saying text/html or possibly text/html; charset=iso-8859-1 -- so the client displays the string incorrectly. Part of your openacs-japanese-325-patches solves that, but without such a change, there really is an issue displaying .html files that have Latin-1 characters in them, in OpenACS 3.2.5.

We really should try to solve this... so I'm making an attempt, using Henry's patchset as a starting point. The result so far is in the SDM as patch #44. I'd be happy if Henry and others could check this out and report how well or badly it works for them :-)

Posted by Jay Dubanik on
Question about the patches to handle different charsets in ACS4.5.
I understand that aolserver3.3.1 ad13 has all patches already in, but what about the patches for ACS?

Were those patches ever applied to ver.4.5, or do I have to apply them, and if yes then where do I find them?